Plan de Réponse aux Incidents (PRI)

Définition

Le Plan de Réponse aux Incidents (PRI), ou Incident Response Plan (IRP) en anglais, est le document de référence qui décrit qui fait quoi, quand et comment lorsqu'un incident de sécurité survient. Il ne s'agit pas d'une simple procédure technique : c'est un dispositif organisationnel qui articule détection, décision, action technique, communication interne et externe, et retour d'expérience. Deux référentiels structurent la quasi-totalité des PRI existants : le cycle PICERL (Preparation, Identification, Containment, Eradication, Recovery, Lessons learned), popularisé par le SANS, et le NIST SP 800-61, qui regroupe les phases en quatre blocs (préparation ; détection et analyse ; confinement, éradication et récupération ; activité post-incident).

Les phases du cycle PICERL

• Préparation — la seule phase qui se déroule hors incident, et la plus déterminante. Elle couvre la constitution de l'équipe (CSIRT interne ou prestataire de réponse), l'inventaire des actifs critiques, la centralisation des journaux, les playbooks par type de menace, les accès de secours et les exercices de simulation.
• Identification — qualification de l'alerte : est-ce un incident, un faux positif, ou un événement bénin ? On détermine le périmètre compromis, le vecteur initial et le niveau de gravité selon une échelle prédéfinie (P1 à P4 par exemple).
• Confinement — on limite la propagation sans détruire les preuves. Isolation réseau des postes touchés via l'EDR, désactivation de comptes compromis, blocage d'adresses IP en périphérie, coupure d'un tunnel VPN. Le confinement se décline souvent en court terme (stopper l'hémorragie) puis long terme (segmentation temporaire).
• Éradication — suppression effective de la cause : retrait des webshells, révocation des tickets Kerberos, correction de la vulnérabilité exploitée, réinitialisation du compte krbtgt en cas de compromission d'Active Directory.
• Récupération — remise en production progressive à partir de sauvegardes saines, avec surveillance renforcée pendant plusieurs semaines pour détecter une éventuelle persistance résiduelle.
• Leçons apprises (REX) — réunion post-mortem sous 15 jours, chronologie factuelle, plan d'action correctif avec porteurs et échéances, mise à jour du PRI lui-même.

Ce que contient un PRI opérationnel

Un PRI utile tient en une trentaine de pages maximum, complété par des annexes courtes et imprimables. Il doit comporter : la matrice de criticité et les critères de déclenchement ; l'arbre d'escalade avec noms, rôles et coordonnées valables 24/7 ; les délais de notification réglementaires ; les moyens de communication de secours (messagerie hors domaine, boucle téléphonique) car un attaquant présent dans le SI lit potentiellement vos e-mails ; et les playbooks par scénario. Point souvent négligé : le PRI doit exister sous forme papier ou sur support hors ligne, un plan stocké uniquement sur le serveur de fichiers chiffré par le ransomware n'ayant aucune valeur.

Exemples concrets

Ransomware sur un serveur de fichiers. L'alerte remonte du SIEM à 3 h du matin (pic anormal d'écritures). Identification : chiffrement en cours depuis un compte de service. Confinement : isolation du serveur, désactivation du compte, coupure du lien inter-sites. Éradication : recherche du point d'entrée — ici un accès RDP exposé. Récupération : restauration depuis une sauvegarde immuable de J-1. REX : suppression de l'exposition RDP et déploiement du MFA.

Compromission de boîte e-mail (BEC). Un utilisateur signale un e-mail de facturation suspect. L'analyse révèle une règle de transfert automatique créée dans Microsoft 365 et des connexions depuis deux pays. Réponse : révocation des sessions, rotation du mot de passe, suppression de la règle, analyse des journaux d'audit sur 90 jours, notification des tiers destinataires de messages frauduleux.

Liens avec les autres dispositifs

Le PRI s'appuie sur les capacités de détection (SIEM, EDR/XDR, SOC) et alimente en aval le PCA/PRA, qui prend le relais lorsque l'incident dégénère en indisponibilité majeure. Il constitue une exigence explicite de la norme ISO/IEC 27001 (mesure 5.24 à 5.28 de l'annexe A) et de la directive NIS 2, qui impose aux entités essentielles et importantes une alerte précoce sous 24 heures et une notification complète sous 72 heures auprès de l'ANSSI. En cas de fuite de données personnelles, le RGPD (article 33) impose parallèlement une notification à la CNIL sous 72 heures. Ces horloges réglementaires doivent figurer noir sur blanc dans le plan.

Bonnes pratiques

• Tester le plan au moins deux fois par an par un exercice de crise sur table, puis par une simulation technique réaliste.
• Contractualiser avant l'incident un prestataire de réponse (idéalement qualifié PRIS par l'ANSSI) : négocier un contrat en pleine crise coûte des jours.
• Préserver les preuves — capture mémoire et images disque avant toute réinstallation — sous peine de rendre impossibles l'analyse forensique et le dépôt de plainte.
• Désigner un pilote de crise distinct des analystes techniques : celui qui décide ne doit pas être celui qui investigue.
• Préparer les éléments de langage à destination des clients, salariés et médias avant d'en avoir besoin.
• Considérer le PRI comme un document vivant : chaque REX doit produire au moins une modification concrète.