Plan de Réponse à Incident Cyber : Modèle 1 Page (PDF)

Un plan de réponse à incident cyber constitue le document opérationnel le plus critique de votre stratégie de cybersécurité. Pourtant, selon une étude publiée par le Ponemon Institute en 2025, près de 77 % des organisations dans le monde ne disposent toujours pas d'un plan de réponse à incident formalisé et régulièrement testé. En France, la situation est encore plus préoccupante pour les PME et ETI, où ce chiffre dépasse les 85 %. Cette lacune organisationnelle a des conséquences financières majeures : le coût moyen d'une violation de données atteint 4,45 millions de dollars selon IBM Security, mais les organisations dotées d'un plan de réponse testé et d'une équipe CSIRT dédiée réduisent ce coût de 2,66 millions de dollars en moyenne. Ce guide exhaustif vous accompagne dans la construction d'un plan de réponse à incident complet, conforme au référentiel NIST et aux exigences européennes NIS 2, avec un modèle téléchargeable gratuitement prêt à être déployé dans votre organisation.

Pourquoi 77 % des organisations n'ont pas de plan de réponse à incident

Le chiffre est alarmant mais s'explique par plusieurs facteurs structurels. Le premier obstacle est la sous-estimation du risque. De nombreux dirigeants considèrent encore que leur entreprise est « trop petite pour être ciblée » ou que leurs mesures de prévention (antivirus, pare-feu) suffisent à les protéger. Cette perception erronée est contredite par les statistiques : en 2025, 43 % des cyberattaques visaient des PME, précisément parce qu'elles disposent de défenses moins robustes et sont souvent utilisées comme porte d'entrée vers des cibles plus importantes dans la chaîne d'approvisionnement.

Le deuxième obstacle est le manque de compétences internes. La conception d'un plan de réponse à incident requiert des compétences à la croisée de la cybersécurité technique, de la gestion de crise et du droit. Les PME disposent rarement d'un RSSI ou d'une équipe sécurité dédiée. Le recours à des prestataires externes est possible mais représente un investissement que beaucoup ne priorisent pas, jusqu'au jour où l'incident survient.

Le troisième facteur est la complexité perçue. Les référentiels comme le NIST SP 800-61, l'ISO 27035 ou le guide de l'ANSSI sur la gestion des incidents sont des documents volumineux et techniques qui peuvent décourager les organisations les moins matures. C'est précisément pour lever cet obstacle que nous proposons ce guide pratique, accompagné d'un modèle synthétique et actionnable.

Le cadre méthodologique NIST pour la réponse à incident

Le NIST (National Institute of Standards and Technology) a publié en 2012, puis révisé en 2024, le référentiel SP 800-61 « Computer Security Incident Handling Guide » qui constitue la référence mondiale en matière de réponse à incident. Ce référentiel définit un cycle en quatre phases principales qui structurent l'ensemble du processus de réponse.

La phase 1 — Préparation est la phase amont, avant tout incident. Elle englobe la constitution de l'équipe de réponse (CSIRT), l'acquisition et la configuration des outils (SIEM, EDR, forensique), la rédaction des procédures et playbooks, la formation des équipes, et la réalisation d'exercices de simulation. C'est la phase la plus importante car elle conditionne l'efficacité des trois phases suivantes.

La phase 2 — Détection et analyse couvre l'identification des incidents, leur qualification (vrai positif vs faux positif), leur classification par type et sévérité, et l'analyse technique initiale pour comprendre la nature et l'étendue de la compromission.

La phase 3 — Confinement, éradication et récupération constitue le cœur opérationnel de la réponse. Elle vise successivement à limiter la propagation de l'attaque, à éliminer la menace du système d'information, puis à restaurer les services dans un état sain et contrôlé.

La phase 4 — Activité post-incident est consacrée au retour d'expérience : analyse de la chronologie de l'incident, identification des causes racines, évaluation de l'efficacité de la réponse, et mise en œuvre des améliorations nécessaires pour prévenir la récurrence.

Étape 1 — Détection : identifier l'incident le plus tôt possible

La détection est la phase qui détermine le « temps zéro » de votre réponse. Plus la détection est rapide, plus les dommages sont limités. Selon le rapport M-Trends 2025 de Mandiant, le temps médian de détection (dwell time) est de 10 jours au niveau mondial, mais atteint encore 21 jours pour les organisations qui s'appuient uniquement sur la détection interne sans SIEM ni EDR. Chaque jour de présence non détectée d'un attaquant dans votre système augmente exponentiellement les dommages potentiels.

Les sources de détection sont multiples et doivent être organisées pour maximiser la couverture. La première source est le SIEM (Security Information and Event Management), qui centralise et corrèle les journaux d'événements de l'ensemble des composants du SI : pare-feu, serveurs, postes de travail, applications, contrôleurs de domaine Active Directory, proxy web, serveurs de messagerie. Le SIEM applique des règles de corrélation et des modèles de détection comportementale pour identifier des séquences d'événements suspectes qui, prises individuellement, pourraient passer inaperçues.

La deuxième source est l'EDR (Endpoint Detection and Response), déployé sur les postes de travail et serveurs. Contrairement à l'antivirus traditionnel qui repose sur des signatures, l'EDR analyse en continu le comportement des processus, des fichiers et des connexions réseau pour détecter des activités malveillantes : exécution de PowerShell obfusqué, tentatives de mouvement latéral, élévation de privilèges suspecte, chiffrement massif de fichiers (indicateur de ransomware).

La troisième source, souvent sous-estimée, est le signalement par les utilisateurs. Un collaborateur qui reçoit un e-mail de phishing, qui constate un comportement anormal de son poste de travail, ou qui est contacté par un tiers signalant une fuite de données est une source de détection précieuse. La charte informatique doit encourager le signalement immédiat et garantir l'absence de sanction pour le signaleur de bonne foi.

D'autres sources complètent le dispositif : les flux de Threat Intelligence (indicateurs de compromission partagés par les CERT, les ISAC sectoriels et les éditeurs de sécurité), les scanners de vulnérabilités qui détectent l'exploitation active de failles, les systèmes de détection d'intrusion réseau (NIDS/NIPS), et les signalements externes (CERT-FR, partenaires, clients, forces de l'ordre).

Comment mettre en place une détection efficace avec des moyens limités ?

Les PME qui ne disposent pas d'un SOC interne peuvent s'appuyer sur plusieurs dispositifs accessibles : un SOC managé (Managed Detection and Response — MDR) qui assure une surveillance 24/7 externalisée, le déploiement d'un EDR cloud avec alerting automatique (solutions comme Microsoft Defender for Endpoint, SentinelOne ou CrowdStrike proposent des offres adaptées aux PME), et la configuration d'alertes basiques dans les journaux d'événements Windows (Event ID 4625 pour les échecs d'authentification, 4720 pour la création de comptes, 4672 pour les connexions avec privilèges élevés).

Étape 2 — Qualification : évaluer la gravité avec une matrice de sévérité

Une fois l'incident détecté, il doit être qualifié rapidement pour déterminer le niveau de réponse approprié. La qualification consiste à évaluer trois dimensions : la nature de l'incident (quel type d'attaque), son impact (quels systèmes, quelles données, quels processus métier sont affectés), et son urgence (quelle est la vitesse de propagation, y a-t-il un risque d'aggravation imminente).

La matrice de sévérité est l'outil central de la qualification. Nous recommandons une échelle à quatre niveaux :

Sévérité 1 — Critique : l'incident affecte la continuité d'activité de l'organisation ou implique une compromission massive de données personnelles. Exemples : ransomware chiffrant les serveurs de production, exfiltration avérée de la base clients, compromission du contrôleur de domaine Active Directory, attaque DDoS rendant les services indisponibles. Réponse : mobilisation immédiate de l'ensemble du CSIRT, activation de la cellule de crise, notification des dirigeants et du DPO dans l'heure.

Sévérité 2 — Élevée : l'incident affecte un système important mais ne compromet pas la continuité d'activité globale. Exemples : compromission d'un serveur web, phishing ciblé ayant conduit à la compromission de comptes utilisateurs avec accès à des données sensibles, malware actif sur plusieurs postes de travail. Réponse : mobilisation du CSIRT dans les 2 heures, escalade vers le management si nécessaire.

Sévérité 3 — Modérée : l'incident a un impact limité et est maîtrisable avec les ressources courantes. Exemples : infection par un adware sur un poste isolé, tentative de phishing détectée sans compromission, vulnérabilité critique découverte mais non encore exploitée. Réponse : traitement par l'équipe de sécurité dans les 24 heures.

Sévérité 4 — Faible : l'incident est mineur et n'a pas d'impact opérationnel. Exemples : scan de ports détecté sans suite, e-mail de phishing générique bloqué par le filtre, alerte de faux positif confirmée. Réponse : documentation et traitement dans les 72 heures.

Étape 3 — Confinement : limiter la propagation de l'attaque

Le confinement est la première action de remédiation et vise à stopper la propagation de l'attaque sans détruire les preuves nécessaires à l'investigation forensique. Cette étape requiert un équilibre délicat entre la réactivité (agir vite pour limiter les dommages) et la préservation (ne pas écraser les traces de l'attaquant).

Le confinement se décline en trois stratégies complémentaires. Le confinement court terme vise à stopper immédiatement la menace active : isolation réseau du ou des systèmes compromis (déconnexion du réseau LAN, désactivation du port switch, modification de VLAN), verrouillage des comptes utilisateurs compromis dans Active Directory, blocage des adresses IP et domaines malveillants sur le pare-feu et le proxy, désactivation des règles de redirection de messagerie suspectes.

Le confinement long terme met en place des mesures plus durables permettant de maintenir l'activité métier pendant que l'éradication est en cours : mise en place d'une segmentation réseau renforcée, déploiement de règles de filtrage additionnelles, redirection du trafic suspect vers un sinkhole, activation de la journalisation renforcée pour surveiller d'éventuelles tentatives de réinfection.

La préservation des preuves doit être intégrée à chaque action de confinement. Avant d'isoler un système, il est essentiel de capturer l'état de la mémoire vive (RAM dump) qui contient des artefacts volatils précieux (processus actifs, connexions réseau en cours, clés de chiffrement en mémoire). Les journaux d'événements doivent être sauvegardés sur un support externe et horodatés. En cas de suspicion d'infraction pénale, la chaîne de preuves doit être documentée de manière à garantir leur recevabilité devant un tribunal.

Quelles actions de confinement pour un ransomware ?

En cas de ransomware, les actions de confinement spécifiques incluent : déconnexion immédiate de tous les partages réseau (SMB), isolation du ou des postes source de l'infection, vérification et isolation des systèmes de sauvegarde (pour empêcher leur chiffrement), désactivation des tâches planifiées et scripts GPO qui pourraient servir de mécanisme de propagation, et blocage des communications vers les serveurs de commande et contrôle (C2) identifiés. Il est crucial de ne jamais éteindre les machines infectées tant que la mémoire n'a pas été capturée, car l'extinction détruit les artefacts volatils.

Étape 4 — Éradication : éliminer complètement la menace

L'éradication vise à supprimer toute trace de l'attaquant du système d'information. Cette phase est souvent plus complexe qu'elle n'y paraît, car les attaquants sophistiqués déploient des mécanismes de persistance multiples pour survivre aux tentatives de nettoyage : backdoors dans le registre Windows, tâches planifiées malveillantes, services Windows détournés, implants dans le firmware, comptes de service compromis, Golden Ticket Kerberos dans Active Directory.

L'éradication comprend plusieurs actions complémentaires. La suppression des malwares sur tous les systèmes affectés, en utilisant des outils spécialisés (Malwarebytes, HitmanPro, ESET Online Scanner) et en vérifiant les mécanismes de persistance courants : clés de registre Run/RunOnce, dossier Startup, tâches planifiées (schtasks), services Windows, WMI subscriptions, DLL hijacking.

La réinitialisation des identifiants compromis est une étape critique souvent sous-estimée. Si un attaquant a obtenu des identifiants d'administrateur de domaine, la simple suppression du malware est insuffisante : il peut revenir en utilisant les mots de passe volés. Il faut réinitialiser tous les mots de passe des comptes compromis ou potentiellement compromis, révoquer les tickets Kerberos (krbtgt reset — deux fois à 12 heures d'intervalle), invalider les tokens OAuth et les sessions actives, et régénérer les certificats si nécessaire.

L'application des correctifs (patches) est indispensable si l'attaquant a exploité une vulnérabilité connue pour pénétrer le système. L'identification de la vulnérabilité exploitée (CVE) et son correction empêchent une nouvelle compromission par le même vecteur. Plus largement, c'est l'occasion de corriger l'ensemble des vulnérabilités critiques identifiées lors de l'investigation.

La reconstruction des systèmes est parfois nécessaire lorsque le niveau de compromission est tel qu'il est impossible de garantir l'intégrité du système après nettoyage. Dans ce cas, il est préférable de reconstruire les serveurs à partir d'images de référence saines et de restaurer les données depuis des sauvegardes vérifiées.

Étape 5 — Récupération : restaurer les services de manière contrôlée

La phase de récupération vise à remettre en production les systèmes de manière progressive et contrôlée, en s'assurant qu'aucune trace de compromission ne subsiste. Cette phase ne doit pas être précipitée : une restauration trop rapide sans vérification suffisante peut conduire à une réinfection immédiate si un mécanisme de persistance a échappé à l'éradication.

La récupération suit un ordre de priorité défini par le plan de continuité d'activité (PCA) de l'organisation : les systèmes critiques pour l'activité métier sont restaurés en premier (ERP, messagerie, bases de données clients, systèmes de production), suivis des systèmes importants (outils collaboratifs, applications métier secondaires), puis des systèmes non critiques (environnements de développement, outils internes non essentiels).

Chaque système restauré fait l'objet d'une validation technique avant sa remise en production : scan antimalware complet, vérification de l'intégrité des fichiers système (hash comparison), contrôle des comptes et des permissions, test de connectivité et de fonctionnement applicatif, vérification de l'absence de communication vers des adresses suspectes (analyse du trafic sortant pendant une période d'observation).

Une surveillance renforcée est mise en place pendant les semaines suivant la restauration. Les seuils d'alerte du SIEM et de l'EDR sont abaissés, les journaux sont analysés quotidiennement, et toute anomalie fait l'objet d'une investigation immédiate. Cette période de vigilance accrue dure généralement de 2 à 4 semaines selon la gravité de l'incident initial.

Étape 6 — Retour d'expérience : transformer l'incident en amélioration

Le retour d'expérience (REX), également appelé lessons learned ou post-incident review, est la phase la plus souvent négligée mais l'une des plus précieuses. Elle consiste à analyser l'ensemble du cycle de l'incident pour identifier les forces et les faiblesses de la réponse et mettre en œuvre des améliorations concrètes.

Le REX doit être réalisé dans un délai de 5 à 10 jours ouvrés après la clôture de l'incident, suffisamment tôt pour que les souvenirs soient frais mais avec assez de recul pour une analyse objective. Il réunit tous les acteurs impliqués dans la réponse : équipe technique (CSIRT, administrateurs système, développeurs), management, communication, juridique, DPO.

La réunion de REX produit un rapport structuré comprenant : la chronologie détaillée de l'incident (timeline), depuis le premier indicateur de compromission jusqu'à la clôture, avec les heures précises de chaque action ; l'analyse des causes racines (root cause analysis) utilisant des méthodes comme les « 5 pourquoi » ou le diagramme d'Ishikawa ; l'évaluation de la réponse (ce qui a bien fonctionné, ce qui a mal fonctionné, ce qui a été improvisé) ; et un plan d'actions correctives priorisé avec des responsables et des échéances.

Les améliorations issues du REX peuvent concerner la prévention (durcissement de la configuration, correction de vulnérabilités, segmentation réseau), la détection (nouvelles règles SIEM, amélioration des playbooks EDR), la réponse (mise à jour des procédures, acquisition d'outils manquants, formation des équipes), et la gouvernance (mise à jour de la politique de sécurité, révision de la charte informatique, renforcement des clauses contractuelles avec les prestataires).

Construire votre CSIRT : composition et rôles

Le CSIRT (Computer Security Incident Response Team) est l'équipe chargée de piloter la réponse aux incidents de sécurité. Sa composition dépend de la taille de l'organisation, mais certains rôles sont indispensables quelle que soit la structure.

Le responsable du CSIRT (Incident Manager) est le chef d'orchestre de la réponse. Il prend les décisions tactiques, coordonne les équipes, assure la communication avec le management et les parties prenantes externes, et valide le passage d'une phase à la suivante. Ce rôle est généralement tenu par le RSSI ou, en son absence, par le DSI ou un responsable technique expérimenté.

Les analystes techniques constituent le cœur opérationnel de l'équipe. Ils réalisent l'investigation technique (analyse des logs, forensique, reverse engineering de malware), mettent en œuvre les actions de confinement et d'éradication, et assurent la restauration technique des systèmes. Dans une PME, ces rôles peuvent être tenus par les administrateurs système et réseau formés à la réponse à incident, éventuellement appuyés par un prestataire externe spécialisé.

Le DPO (Délégué à la Protection des Données) intervient dès qu'une violation de données personnelles est suspectée. Il évalue l'impact sur les droits et libertés des personnes concernées, prépare la notification à la CNIL si nécessaire, et conseille sur la communication aux personnes affectées.

Le responsable de la communication gère les aspects communicationnels de l'incident : communication interne (information des collaborateurs), communication externe (clients, partenaires, fournisseurs), relations avec les médias si nécessaire, et coordination avec les relations publiques. En cas de crise majeure, une communication mal gérée peut causer plus de dommages réputationnels que l'incident technique lui-même.

Le conseiller juridique intervient pour évaluer les obligations légales de notification (RGPD, NIS 2), conseiller sur la préservation des preuves en vue d'éventuelles poursuites judiciaires, et anticiper les conséquences juridiques de l'incident (responsabilité contractuelle envers les clients, sanctions administratives, actions en justice).

Le plan de communication de crise cyber

La communication pendant un incident de sécurité est un exercice délicat qui nécessite une préparation minutieuse. Le plan de communication doit définir quatre circuits de communication distincts, chacun avec ses propres messages, canaux et calendrier.

La communication interne est prioritaire. Les collaborateurs doivent être informés rapidement de la situation (sans détails techniques qui pourraient être exploités par l'attaquant s'il a encore accès au SI), des mesures prises, et des consignes à suivre (ne pas utiliser certains systèmes, changer leurs mots de passe, être vigilants face à d'éventuelles tentatives de phishing ciblé). Le canal de communication doit être sécurisé et distinct du SI potentiellement compromis : Signal, WhatsApp, ou SMS pour les communications urgentes plutôt que la messagerie d'entreprise qui pourrait être surveillée par l'attaquant.

La communication externe vers les clients et partenaires doit être transparente et factuelle. Elle doit indiquer la nature de l'incident (sans révéler de détails techniques exploitables), les mesures prises pour y remédier, l'impact sur les services fournis, et les actions recommandées aux clients (changement de mot de passe, surveillance des relevés bancaires). Le RGPD impose la notification des personnes concernées « dans les meilleurs délais » lorsque la violation est susceptible d'engendrer un risque élevé pour leurs droits et libertés.

La communication avec les autorités est encadrée par la réglementation. Le RGPD impose la notification à la CNIL dans les 72 heures suivant la constatation de la violation (Article 33). La directive NIS 2 impose une alerte précoce au CSIRT national (CERT-FR en France) dans les 24 heures suivant la détection d'un incident significatif, suivie d'un rapport complet dans les 72 heures et d'un rapport final dans le mois suivant la résolution de l'incident.

La communication médiatique, si elle est nécessaire, doit être centralisée et maîtrisée. Un seul porte-parole est désigné, les éléments de langage sont validés par la direction et le conseil juridique, et le message est factuel et rassurant sans minimiser la gravité de la situation. Il est recommandé de préparer à l'avance des modèles de communiqués de presse adaptables à différents scénarios d'incident.

Obligations NIS 2 en matière de réponse à incident

La directive européenne NIS 2 (Network and Information Security Directive), transposée en droit français, renforce considérablement les obligations des organisations en matière de gestion des incidents de sécurité. Son champ d'application est étendu : elle couvre les « entités essentielles » (énergie, transport, santé, eau, infrastructure numérique, administration publique, espace) et les « entités importantes » (services postaux, gestion des déchets, fabrication, industrie alimentaire, recherche, fournisseurs numériques).

En matière de notification d'incident, NIS 2 impose un processus en trois étapes strictement encadré dans le temps. L'alerte précoce (early warning) doit être transmise au CSIRT compétent dans les 24 heures suivant la détection d'un incident significatif. Elle doit indiquer si l'incident est susceptible d'avoir été causé par un acte malveillant et s'il pourrait avoir un impact transfrontalier. Le rapport d'incident complet doit être soumis dans les 72 heures, avec une évaluation initiale de l'incident, de sa gravité et de son impact, ainsi que des indicateurs de compromission le cas échéant. Le rapport final est dû dans le mois suivant la résolution de l'incident et contient une description détaillée, l'analyse des causes racines, les mesures correctives appliquées et l'impact transfrontalier éventuel.

NIS 2 impose également des obligations de gouvernance : les organes de direction des entités concernées doivent approuver les mesures de gestion des risques (y compris le plan de réponse à incident) et suivre une formation en cybersécurité. Les dirigeants peuvent être tenus personnellement responsables en cas de manquement à ces obligations.

Les exercices de simulation : tester votre plan avant l'incident réel

Un plan de réponse à incident qui n'est pas testé régulièrement n'est qu'un document théorique. Les exercices de simulation (tabletop exercises) permettent de vérifier que les procédures sont connues, comprises et applicables dans des conditions proches de la réalité.

L'exercice tabletop est le format le plus accessible. Il réunit autour d'une table (physique ou virtuelle) les membres du CSIRT et les parties prenantes clés. Un animateur présente un scénario d'incident évoluant par étapes (injection de nouveaux éléments toutes les 15-20 minutes) et les participants doivent décrire les actions qu'ils prendraient, les décisions qu'ils prendraient, et les communications qu'ils effectueraient. Aucune action technique réelle n'est effectuée : l'exercice teste la connaissance des procédures, la coordination entre les équipes et la prise de décision sous pression.

Les scénarios recommandés incluent : un ransomware chiffrant les serveurs critiques un vendredi soir (test de la disponibilité de l'équipe hors heures ouvrées), une exfiltration de données clients détectée par un signalement externe (test de la communication de crise et de la notification RGPD), un phishing ciblé ayant compromis le compte d'un dirigeant (test de la détection et de la gestion des comptes à privilèges), et une attaque supply chain via un fournisseur de logiciel compromis (test de la coordination avec les tiers).

La fréquence recommandée est d'un exercice tabletop par trimestre et d'un exercice technique (red team / blue team) par an pour les organisations les plus matures. Chaque exercice fait l'objet d'un rapport identifiant les points forts, les points faibles et les actions correctives, qui alimentent la mise à jour du plan de réponse.

Le répertoire de contacts : votre annuaire de crise

En situation de crise, chaque minute compte. Le répertoire de contacts est un document simple mais vital qui doit être accessible rapidement, y compris si le système d'information est indisponible. Il doit contenir les coordonnées complètes (téléphone mobile, e-mail personnel de secours) de toutes les personnes susceptibles d'être mobilisées en cas d'incident.

Le répertoire doit inclure au minimum : les membres du CSIRT interne (RSSI, administrateurs système, DPO, directeur juridique, directeur de la communication, direction générale), les prestataires externes de réponse à incident (société de forensique, cabinet juridique spécialisé, agence de communication de crise, prestataire d'assurance cyber), les autorités compétentes (CERT-FR : cert-fr@ssi.gouv.fr et 01 71 75 84 68, CNIL : service des plaintes, police/gendarmerie spécialisée cyber, préfecture), et les partenaires critiques (hébergeur, opérateur télécom, éditeurs de logiciels clés).

Ce répertoire doit être disponible sous forme papier (imprimé et conservé dans un endroit sûr accessible au RSSI et au directeur général) ET sous forme numérique sur un système indépendant du SI (téléphone mobile du RSSI, cloud personnel sécurisé). Il doit être mis à jour trimestriellement et testé annuellement (vérification que les numéros sont toujours valides).

Intégration du plan avec le registre des incidents

Le plan de réponse à incident est indissociable du registre des incidents de sécurité. Le registre constitue la mémoire organisationnelle de tous les incidents survenus, de leur traitement et des leçons tirées. Il alimente le plan de réponse en données concrètes : types d'incidents les plus fréquents, temps moyen de détection et de résolution, efficacité des mesures de confinement, etc.

Le plan doit prévoir les modalités de documentation des incidents dans le registre : qui est responsable de la saisie, quelles informations doivent être renseignées à chaque étape, quels sont les délais de mise à jour, et comment le registre est exploité pour l'amélioration continue. La conformité NIS 2 et RGPD impose la tenue de ce registre de manière rigoureuse et auditable.

Outils essentiels pour la réponse à incident

Un CSIRT efficace s'appuie sur une trousse à outils préparée à l'avance et régulièrement mise à jour. Les outils se répartissent en plusieurs catégories fonctionnelles.

Les outils de forensique permettent l'investigation technique : FTK Imager (acquisition d'images disque et mémoire), Volatility (analyse de la mémoire vive), Autopsy/The Sleuth Kit (analyse de systèmes de fichiers), Wireshark (analyse de captures réseau), et KAPE (collecte rapide d'artefacts Windows). Pour les environnements Active Directory, des outils comme BloodHound permettent de visualiser les chemins d'attaque et les comptes compromis. Consultez notre guide Active Directory pour les aspects de sécurisation spécifiques.

Les outils de confinement et éradication incluent : les consoles de gestion EDR (pour isoler des postes à distance), les outils de gestion Active Directory (pour verrouiller des comptes, réinitialiser des mots de passe, révoquer des sessions), les outils de déploiement de patches (WSUS, SCCM, Intune), et les scanners de vulnérabilités (Nessus, OpenVAS, Qualys).

Les outils de communication et coordination doivent être indépendants du SI principal : messagerie chiffrée (Signal), plateforme de gestion de crise (PagerDuty, OpsGenie), outil de documentation partagée (Google Docs, Notion — sur des comptes distincts du SI compromis), et conférence téléphonique (Teams sur un tenant dédié, Zoom, numéro de conférence de secours).

Questions fréquentes sur le plan de réponse à incident

À partir de quelle taille d'entreprise faut-il un plan de réponse à incident ?

Toute entreprise traitant des données numériques a besoin d'un plan de réponse à incident, quel que soit sa taille. La complexité du plan doit être proportionnée : une TPE de 5 personnes peut se contenter d'une procédure de 2-3 pages identifiant les contacts d'urgence, les premières actions de confinement et les prestataires à appeler. Une ETI de 500 personnes aura besoin d'un plan détaillé de 30-50 pages avec des playbooks spécifiques par type d'incident. L'essentiel est d'avoir un plan écrit, connu et testé.

Combien de temps faut-il pour élaborer un plan de réponse à incident ?

Pour une PME partant de zéro, comptez 4 à 8 semaines pour élaborer un plan complet : 1 semaine pour l'état des lieux et l'inventaire des actifs critiques, 2-3 semaines pour la rédaction des procédures et playbooks, 1 semaine pour la constitution et la formation de l'équipe, et 1-2 semaines pour le premier exercice de simulation et les ajustements. L'utilisation de notre modèle permet de réduire significativement ce délai en fournissant une base structurée et pré-remplie.

Quelle est la différence entre un PCA et un plan de réponse à incident ?

Le PCA (Plan de Continuité d'Activité) et le plan de réponse à incident sont complémentaires mais distincts. Le plan de réponse à incident se concentre sur la détection, le confinement et l'éradication de la menace technique. Le PCA se concentre sur le maintien ou la reprise des activités métier critiques, quel que soit le type de sinistre (cyberattaque, incendie, inondation, pandémie). En cas d'incident cyber majeur, les deux plans sont activés conjointement : le plan de réponse guide la remédiation technique tandis que le PCA organise la continuité des services.

Faut-il notifier la CNIL en cas d'incident de sécurité sans fuite de données ?

La notification CNIL est obligatoire uniquement en cas de violation de données personnelles au sens du RGPD, c'est-à-dire une violation de la confidentialité, de l'intégrité ou de la disponibilité de données à caractère personnel. Un incident de sécurité purement technique (défacement de site web sans données personnelles, DDoS sur un service sans données personnelles) ne requiert pas de notification CNIL. Cependant, tout incident doit être documenté dans le registre des incidents, et les incidents significatifs doivent être notifiés au titre de NIS 2 si l'entité est concernée.

Peut-on externaliser complètement la réponse à incident ?

L'externalisation de la réponse à incident est courante et recommandée pour les organisations qui ne disposent pas de compétences internes suffisantes. Cependant, elle ne peut être totale : l'entreprise doit conserver la maîtrise des décisions stratégiques (communiquer ou non, arrêter ou non un système de production, notifier les autorités) et la connaissance de son propre système d'information. Le prestataire externe apporte l'expertise technique forensique et les méthodologies de réponse, mais il a besoin de la coopération active des équipes internes qui connaissent l'infrastructure, les applications et les processus métier.

Comment choisir un prestataire de réponse à incident ?

Plusieurs critères sont déterminants : la certification PRIS (Prestataire de Réponse aux Incidents de Sécurité) délivrée par l'ANSSI est le label de référence en France ; la disponibilité 24/7 avec un engagement de temps de réponse (SLA) ; l'expérience avérée sur des incidents similaires à vos risques principaux ; la couverture géographique (intervention sur site si nécessaire) ; et l'existence d'un contrat de rétainer (retainer agreement) qui garantit la disponibilité des ressources en cas de crise, moyennant un abonnement annuel.

Comment intégrer la cyber-assurance dans le plan de réponse ?

La cyber-assurance doit être intégrée dès la phase de préparation. Le contrat d'assurance prévoit généralement des obligations de notification du sinistre dans un délai court (souvent 48 à 72 heures), des prestataires agréés pour la forensique et la remédiation (l'utilisation de prestataires non agréés peut affecter la couverture), et des plafonds de garantie par type d'incident. Le plan de réponse doit prévoir l'activation du contrat d'assurance comme l'une des premières actions du responsable d'incident, avant même le début de la forensique, pour garantir la prise en charge des frais.

À quelle fréquence faut-il mettre à jour le plan de réponse à incident ?

Le plan doit être révisé annuellement de manière systématique, et mis à jour ponctuellement après chaque incident réel ou exercice de simulation (intégration des leçons apprises), après chaque changement majeur du SI (migration cloud, fusion/acquisition, déploiement d'un nouvel ERP), après chaque évolution réglementaire significative (NIS 2, mise à jour des recommandations ANSSI), et après chaque changement organisationnel affectant le CSIRT (départ d'un membre clé, réorganisation de la DSI).

Modèle de chronologie d'incident (timeline template)

La chronologie est le document central de tout incident de sécurité. Elle constitue à la fois un outil opérationnel (suivi en temps réel des actions) et une pièce d'archive (documentation pour le REX, l'assurance, et les éventuelles procédures judiciaires). Le modèle que nous proposons structure la timeline en colonnes : date/heure (au format ISO 8601, fuseau horaire UTC), source (qui a détecté ou reporté l'information), événement (description factuelle), action prise (mesure de réponse), responsable (personne ayant pris la décision ou réalisé l'action), et statut (en cours, terminé, en attente).

La timeline doit être tenue en temps réel pendant l'incident. Un membre de l'équipe (le « scribe ») est dédié à cette tâche pour ne pas surcharger les analystes techniques. Chaque entrée doit être factuelle et horodatée précisément. Les impressions, hypothèses et analyses doivent être distinguées des faits observables.

Inspiré des recommandations de cybermalveillance.gouv.fr (licence Etalab 2.0), de l'ANSSI et de la CNIL.

Conclusion

La prévention et la préparation restent les meilleures armes face aux cybermenaces. Téléchargez cette ressource, diffusez-la dans votre organisation et n'hésitez pas à nous contacter pour un accompagnement personnalisé.