Playbook 72h : que faire dans les 72 heures après une fuite d'identifiants

Quand une fuite d’identifiants est détectée, les 72 premières heures déterminent l’impact réel de l’incident. Ce playbook propose une chronologie horodatée, alignée sur les délais réglementaires européens (RGPD 72h, NIS2 24h/72h, DORA 4h/24h/1 mois) et sur les bonnes pratiques de réponse à incident publiées par le NIST et l’ANSSI. Il s’adresse aux RSSI, responsables sécurité opérationnelle et équipes IT qui doivent transformer une alerte en réponse cadrée et défendable face aux superviseurs.

Playbook en 50 mots. H+0 détection, H+1 cellule de crise, H+4 endiguement (révocation sessions, reset mots de passe, MFA), H+12 investigation et périmètre, H+24 notification réglementaire, H+48 communication interne et externe, H+72 remédiation et durcissement. Au-delà de 72h, post-mortem et plan de durcissement. Chronométrage écrit du début à la fin.

Pourquoi 72 heures ? Les délais réglementaires européens

La fenêtre de 72 heures n’est pas arbitraire. Elle est imposée par plusieurs régimes réglementaires européens qui se cumulent fréquemment lors d’une fuite d’identifiants. Connaître ces délais avant l’incident est la condition pour ne pas découvrir la contrainte sous pression.

RGPD : 72 heures pour notifier la CNIL. L’article 33 du règlement (UE) 2016/679 impose au responsable du traitement de notifier toute violation de données à caractère personnel à l’autorité de contrôle compétente (en France, la CNIL) dans les meilleurs délais et au plus tard 72 heures après en avoir pris connaissance. Le point de départ est la prise de connaissance, c’est-à-dire le moment où l’organisme a une certitude raisonnable que l’incident a eu lieu et a touché des données personnelles. Toute fuite d’identifiants comprenant un email, un identifiant nominatif ou des données associées entre dans le périmètre RGPD.

NIS2 : alerte précoce sous 24 heures, notification sous 72 heures. La directive (UE) 2022/2555, transposée en France, impose aux entités essentielles et importantes une alerte précoce à l’autorité nationale compétente (ANSSI) dans les 24 heures suivant la prise de connaissance d’un incident significatif, suivie d’une notification complète dans les 72 heures et d’un rapport final dans le mois. Les seuils de significativité reposent sur la perturbation opérationnelle, l’impact économique et le nombre d’utilisateurs touchés.

DORA : 4 heures, 24 heures, 1 mois. Pour les entités financières assujetties au règlement (UE) 2022/2554 (DORA), les délais sont plus courts. Une notification initiale est due sous 4 heures à compter de la classification de l’incident comme majeur (et au plus tard 24 heures après la détection), un rapport intermédiaire sous 72 heures, et un rapport final dans un délai d’un mois.

Ces régimes peuvent se cumuler. Une banque européenne victime d’une fuite d’identifiants relevant de données personnelles d’un service essentiel doit potentiellement notifier la CNIL (RGPD), l’ANSSI (NIS2) et l’ACPR (DORA) dans des délais différents. L’objectif du playbook 72h est de tenir simultanément ces trois exigences sans improvisation.

H+0 à H+1 : Détection et qualification

Durée : 60 minutes. Objectif : transformer une alerte en incident qualifié.

Sources d’alerte

Une fuite d’identifiants peut être détectée par plusieurs canaux. Les plus rapides sont automatisés. Plateforme externe de détection de fuites de credentials qui surveille les logs d’infostealers, les forums underground et les canaux Telegram. SIEM interne corrélant des connexions suspectes avec des sessions inhabituelles. Signalement d’un partenaire ou d’un fournisseur. Information d’une autorité (ANSSI, CERT-FR). Plus rarement, contact direct d’un attaquant ou découverte fortuite.

Qualification immédiate

Trois questions structurent la qualification dans les 30 premières minutes. La fuite est-elle confirmée (échantillon vérifiable, source identifiée, horodatage de la première observation) ? Quel est le périmètre prévisible (un utilisateur, une équipe, un domaine, un fournisseur) ? Quel est le facteur de gravité initial (services critiques exposés, comptes à privilèges, données réglementées) ?

Mobilisation de la cellule de crise restreinte

À H+30 minutes au plus tard, la cellule de crise restreinte est constituée. Elle compte 3 à 5 personnes : RSSI ou responsable sécurité opérationnelle, ingénieur identité et accès, responsable juridique ou DPO, sponsor direction (DSI ou COMEX), éventuellement un communicant. Le principe de cellule restreinte est emprunté au cadre TIBER-EU et au guide ANSSI « Anticiper et gérer une crise cyber ». Plus le cercle initial est petit, plus la coordination est efficace et plus le risque de fuite d’information ou de communication prématurée est limité.

Chronométrage formel

Dès H+0, ouvrir un journal d’incident horodaté (war room, ticket dédié, document partagé restreint). Toutes les décisions, observations et actions sont consignées avec horodatage UTC. Ce journal est le document de référence en cas d’audit, de notification réglementaire et de post-mortem. Le NIST SP 800-61 rev 2 « Computer Security Incident Handling Guide » en fait un livrable standard de la phase de containment.

H+1 à H+4 : Endiguement immédiat

Durée : 3 heures. Objectif : couper l’accès à l’attaquant sans détruire les preuves.

L’endiguement vise à neutraliser l’utilisation des identifiants compromis le plus vite possible, tout en préservant les éléments d’investigation. C’est la phase la plus opérationnelle du playbook.

Révoquer les sessions actives

Les infostealers volent les cookies de session en plus des identifiants. Un changement de mot de passe seul ne suffit pas : un attaquant peut maintenir l’accès via une session active. Première action : révoquer toutes les sessions sur l’IdP central (Entra ID, Okta, Google Workspace, Keycloak) pour les comptes identifiés comme compromis, ainsi que sur les applications critiques (VPN, console cloud, SaaS sensibles). Sur Entra ID, l’opération se traduit par une révocation de tokens (Revoke-AzureADUserAllRefreshToken). Sur Okta, par une session reset bulk. Sur les SaaS critiques, par un sign-out global de l’organisation.

Forcer le reset des mots de passe

Pour les comptes compromis identifiés, expirer le mot de passe avec changement obligatoire à la prochaine connexion. Cette action s’exécute depuis l’IdP en bulk. Élargir le périmètre aux comptes susceptibles d’être impactés par réutilisation (équipe IT, comptes à privilèges, comptes de service partagés). En cas de doute sur l’étendue, élargir plutôt que rétrécir : un reset trop large coûte une journée de gêne, un reset trop étroit laisse une porte ouverte.

Renforcer ou ré-enrôler le MFA

Sur les comptes compromis sans MFA, activer immédiatement le MFA, idéalement avec des facteurs résistants au phishing (clés FIDO2, passkeys). Sur les comptes avec MFA, vérifier que les facteurs ne sont pas eux-mêmes compromis (numéros de téléphone modifiés, applications TOTP transférées). Si un doute existe, ré-enrôler le MFA. Pour les comptes à privilèges, exiger un facteur matériel.

Isoler les systèmes touchés

Si la fuite révèle une infection par infostealer sur un poste utilisateur, isoler le poste du réseau (déconnexion, mise en quarantaine via EDR) sans l’éteindre, pour préserver les preuves volatiles. Si la compromission a permis un accès à un système, isoler le système au niveau réseau (segmentation, règles firewall) plutôt que de l’arrêter. L’arrêt d’un serveur peut détruire les artefacts mémoire et compliquer l’investigation forensic.

Rotation des secrets applicatifs

Si un compte technique ou un compte de service est compromis, faire tourner les clés d’API, certificats, tokens de service et secrets applicatifs associés. Vérifier les inventaires de secrets (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) et planifier une rotation élargie sur 24 à 48 heures.

H+4 à H+12 : Investigation et périmètre

Durée : 8 heures. Objectif : déterminer l’étendue exacte et le vecteur initial.

L’endiguement immédiat est terminé. L’objectif bascule vers la compréhension. Sans périmètre exact, ni la classification réglementaire ni la communication ne sont possibles.

Forensic logs SIEM et IdP

Extraire 30 à 90 jours de logs sur les comptes compromis : tentatives de connexion, géolocalisation, user agents, applications consultées, opérations d’écriture, modifications de paramètres de compte. Croiser avec les logs SIEM pour repérer les actions latérales (accès à des partages, élévations de privilèges, exfiltration). Le SIEM est ici l’outil pivot, conditionné à la qualité de la rétention et des règles de corrélation.

Identifier les comptes additionnels

Une fuite isolée est rare. Vérifier si d’autres comptes du même utilisateur ou de la même équipe ont été affectés (réutilisation de mots de passe, sessions partagées, postes communs). Croiser avec les sources externes de détection de fuites d’identifiants pour identifier d’autres credentials du même domaine présents dans des bases d’infostealers.

Vecteur initial

Reconstituer comment l’attaquant a obtenu les identifiants. Trois scénarios courants. Infection par infostealer sur un poste utilisateur (RedLine, Lumma, Vidar, StealC) après téléchargement d’un crack ou d’un installeur frauduleux. Phishing avec capture de credentials sur une page miroir, parfois associé à un kit AiTM (adversary-in-the-middle) qui intercepte aussi les cookies de session. Brèche d’un service tiers où l’utilisateur a réutilisé son mot de passe d’entreprise.

Indicateurs de compromission

Documenter les IoC à diffuser dans le SIEM : adresses IP d’attaquant, user agents anormaux, hashes de fichiers malveillants, domaines de C2. Ces IoC alimentent la chasse interne et peuvent être partagés avec le CERT-FR ou un ISAC sectoriel dans le cadre du pilier 5 du règlement DORA pour les entités financières.

Décision de classification

À H+12, la cellule de crise dispose d’éléments suffisants pour classer formellement l’incident. Trois axes : violation de données à caractère personnel au sens RGPD (oui/non, niveau de risque pour les personnes), incident significatif au sens NIS2 (oui/non, seuils de l’ANSSI), incident majeur au sens DORA (oui/non, seuils du règlement délégué (UE) 2024/1772). Cette classification, écrite et horodatée, déclenche les notifications réglementaires.

H+12 à H+24 : Notification réglementaire

Durée : 12 heures. Objectif : notifier les autorités compétentes dans les délais légaux.

CNIL si RGPD applicable

Notifier la CNIL via le téléservice de notification de violations de données personnelles. Délai : 72 heures à compter de la prise de connaissance, mais préparer la notification dès H+12 pour pouvoir transmettre avant H+24 si la classification est tenue. Éléments obligatoires : nature de la violation, catégories et nombre approximatif de personnes concernées, catégories et nombre d’enregistrements, conséquences probables, coordonnées du DPO, mesures prises pour remédier. Une notification incomplète peut être complétée a posteriori si certains éléments restent inconnus à H+72.

ANSSI si NIS2 applicable

L’alerte précoce NIS2 est due dans les 24 heures à compter de la prise de connaissance. Elle se transmet à l’ANSSI via les canaux opérationnels CERT-FR. La notification complète suit dans les 72 heures.

ACPR si DORA applicable

Pour les entités financières, la notification initiale DORA est due dans les 4 heures à compter de la classification (et au plus tard 24 heures après détection). Elle se transmet à l’ACPR pour les banques et assurances, à l’AMF pour les sociétés de gestion. Le canal de remise est précisé dans les ITS publiées par les ESAs.

Régulateurs sectoriels supplémentaires

Selon le secteur d’activité, des notifications sectorielles peuvent s’ajouter : ARCEP pour les opérateurs télécoms, ANS pour les opérateurs de santé, autorités étrangères si l’entité opère au-delà de l’UE. Le principe est de notifier large et tôt plutôt que de découvrir tardivement une obligation manquée.

Documentation pour les notifications

Constituer une fiche d’incident type, réutilisée pour toutes les notifications, avec : horodatage de détection, horodatage de classification, périmètre confirmé, nombre de personnes/clients/utilisateurs touchés, nature des données impactées, mesures d’endiguement engagées, mesures de remédiation prévues, point de contact unique. Cette fiche évite les incohérences entre régulateurs.

H+24 à H+48 : Communication interne et externe

Durée : 24 heures. Objectif : informer les bonnes audiences avec le bon niveau de détail.

Communication interne aux collaborateurs concernés

Message direct aux utilisateurs dont les comptes sont compromis : faits (votre compte X a été identifié dans une fuite), actions immédiates (changer le mot de passe, ré-enrôler MFA, signaler toute activité anormale), point de contact pour questions. Pas de détail technique sur la chaîne d’attaque. Un mail trop technique ou alarmiste génère un volume de tickets ingérable.

Communication interne large

Si l’incident touche plus de 50 personnes ou plusieurs équipes, prévoir une communication large (intranet, all-hands, message du COMEX) qui précise : ce qui s’est passé, ce qui est fait, ce qui est attendu des collaborateurs, ce qui n’est pas confirmé. Cette communication est validée par le juridique et la cellule de crise avant diffusion.

Communication aux clients impactés

Si des données clients sont touchées, un courrier ou un email aux clients concernés est obligatoire au titre du RGPD lorsque la violation est susceptible d’engendrer un risque élevé pour les droits et libertés des personnes. Le contenu suit le modèle CNIL : faits, périmètre, conséquences possibles, mesures prises, recommandations (changer le mot de passe sur les services tiers où il est réutilisé, surveiller son compte, signaler toute fraude). Joindre un point de contact dédié, distinct du support standard.

Communication aux partenaires et fournisseurs

Si un fournisseur est lié à l’incident (origine, impact ou périmètre), prévoir une communication spécifique avec accord NDA si nécessaire. Si des partenaires utilisent vos services, les informer du périmètre côté chaîne d’approvisionnement.

Communication publique

Pas de communication publique avant validation par la cellule de crise et le juridique. Si une demande presse arrive avant H+48, communiquer un message bref factuel sans détail. La communication publique structurée intervient en général après H+72, une fois le périmètre stabilisé.

H+48 à H+72 : Remédiation et durcissement

Durée : 24 heures. Objectif : refermer durablement la brèche et préparer le rapport final.

Correctifs techniques

Patcher les vulnérabilités exploitées si l’incident révèle un défaut technique (CVE non corrigée, mauvaise configuration, exposition publique). Mettre à jour les politiques de mot de passe et MFA si elles étaient laxistes. Activer ou renforcer la détection EDR sur les postes utilisateurs concernés.

Monitoring renforcé

Mettre en place pour 30 à 90 jours un monitoring renforcé sur les comptes touchés, les utilisateurs proches et les systèmes impactés : alertes spécifiques sur connexions inhabituelles, accès aux ressources sensibles, modifications de configuration. Adapter les règles SIEM en fonction des IoC identifiés.

Lessons learned préliminaires

À H+72, la cellule de crise tient une réunion de retours d’expérience à chaud. Trois questions : qu’est-ce qui a bien fonctionné, qu’est-ce qui a manqué, quelles décisions auraient été différentes avec un peu plus d’information. Ces retours alimentent le post-mortem complet, livré 2 à 4 semaines plus tard.

Préparation du rapport final

Pour les notifications NIS2 et DORA, un rapport final est attendu dans le mois. Préparer dès H+72 la trame du rapport : chronologie complète, cause racine, périmètre exact, mesures correctives, indicateurs (MTTD, MTTR, durée d’exposition). Ce rapport est aussi un livrable attendu par les superviseurs en cas d’audit ultérieur.

Au-delà de 72h : Post-mortem et plan de durcissement

Les 72 heures absorbent la phase aiguë. Le travail de fond commence ensuite. Trois livrables structurent cette phase.

Post-mortem complet, livré sous 2 à 4 semaines. Document sans recherche de coupable, qui couvre la chronologie, la cause racine technique et organisationnelle, le périmètre exact, les mesures correctives engagées avec responsable et date de clôture, les axes d’amélioration sur la détection et la classification, les indicateurs de réponse (MTTD, MTTR). Le post-mortem est présenté au COMEX ou au comité sécurité, archivé dans le registre d’incidents et alimente le programme d’exercices de l’année suivante.

Plan de durcissement à 90 jours. Liste d’actions techniques et organisationnelles avec priorisation : généralisation du MFA résistant au phishing, renforcement de la détection EDR, segmentation réseau, programme de formation utilisateurs, renforcement de la détection externe via plateforme de surveillance des fuites de credentials, mise à jour des politiques de gestion des accès. Le plan est validé par la direction et son avancement suivi mensuellement.

Mise à jour du playbook. L’incident révèle systématiquement des lacunes du playbook initial. Mettre à jour la procédure, les contacts, les seuils de classification, les modèles de notification. Le playbook est un document vivant, pas un livrable d’audit.

Stealed dans le playbook

Stealed est une plateforme française (hébergée chez Scaleway, fr-par) de détection de fuites d’identifiants qui surveille en temps réel plus de 100 millions de credentials par jour issus de logs d’infostealers, forums underground et canaux Telegram privés. Stealed intervient à plusieurs étapes précises du playbook 72h.

À H+0 : détection avant l’utilisateur. Une alerte se déclenche en quelques minutes lorsqu’un identifiant lié à un domaine surveillé apparaît dans une nouvelle fuite. La latence courte est compatible avec les délais réglementaires les plus stricts (4 heures DORA, 24 heures NIS2). Cette détection précède en général de plusieurs heures à plusieurs jours toute remontée interne classique.

Pendant la phase d’endiguement : alimentation du SIEM/SOAR. L’API REST documentée et les webhooks vers Slack, Teams, Splunk, QRadar, Sentinel permettent d’ingérer les alertes Stealed dans le SIEM de l’entité. Les playbooks SOAR peuvent déclencher automatiquement des actions de containment (révocation de session, expiration de mot de passe, ouverture de ticket d’incident) dès la réception d’une alerte qualifiée.

Pendant l’investigation : périmètre étendu. Le module External Insight permet de surveiller des domaines tiers (sous-traitants, fournisseurs, partenaires) et d’identifier les fuites d’identifiants des collaborateurs de ces fournisseurs sur des sites où ils se connectent au nom de l’entité. Cette visibilité étendue alimente l’analyse de l’origine d’un incident lorsqu’un fournisseur est suspecté, et nourrit la documentation du registre des fournisseurs (utile au pilier 4 de DORA).

Vous gérez actuellement un incident ? Parlez-en avec notre CTO en 30 minutes pour partager votre situation et identifier les leviers de détection externes mobilisables. Si vous préférez tester la plateforme avant tout échange, créez un compte gratuitement pour démarrer la surveillance d’un domaine.

Erreurs fréquentes à éviter

Sous-estimer le périmètre initial. Le réflexe consistant à limiter l’incident au compte unique signalé conduit souvent à découvrir 48 heures plus tard que d’autres comptes étaient touchés. Élargir le périmètre dès l’endiguement est moins coûteux qu’une seconde vague d’incident à H+72.

Communiquer trop tôt. Une communication large avant H+12 sans périmètre stabilisé crée des incohérences entre les messages successifs et alimente le bruit médiatique. Sauf découverte par un tiers, attendre la consolidation des faits.

Oublier le RGPD. Une fuite d’identifiants est presque toujours une violation de données personnelles. Penser à la classification CNIL dès H+1, pas à H+60.

Ne pas chronométrer. Les notifications réglementaires sont calées sur des points de départ précis : prise de connaissance pour le RGPD, classification pour DORA. Sans horodatage écrit, la défense devant un superviseur est fragile.

Ne pas mobiliser le DPO ou le juridique. Les décisions de notification ont un impact juridique. Les sortir du circuit pour aller plus vite revient en général à reprendre toute la décision quelques heures plus tard.

Confondre endiguement et remédiation. L’endiguement coupe l’accès à l’attaquant. La remédiation refait fonctionner les systèmes proprement. Vouloir tout faire en parallèle dans les 4 premières heures dégrade les deux.

Questions fréquentes sur le playbook 72h

Qui mobiliser en premier dans les 60 premières minutes ? Une cellule de crise restreinte (3 à 5 personnes) est mobilisée dès la qualification : RSSI ou responsable sécurité opérationnelle, un ingénieur identité et accès (IAM), un responsable juridique ou DPO, et un sponsor au niveau direction (DSI ou COMEX). Les équipes communication, métiers et support sont mobilisées dans un second cercle dès que le périmètre est cadré. Le principe est d’éviter d’alerter trop largement avant d’avoir une vision factuelle, pour ne pas compromettre l’investigation et ne pas générer de communication prématurée.

Comment décider si la fuite déclenche une notification RGPD, NIS2 ou DORA ? Trois questions à trancher en parallèle dès H+1. RGPD : la fuite touche-t-elle des données à caractère personnel et présente-t-elle un risque pour les droits et libertés des personnes ? Si oui, notification CNIL sous 72 heures. NIS2 : l’entité est-elle essentielle ou importante au sens de la directive et l’incident a-t-il un impact significatif ? Si oui, alerte précoce sous 24 heures et notification sous 72 heures à l’autorité nationale. DORA : l’entité est-elle financière au sens du règlement (UE) 2022/2554 et l’incident est-il classé majeur ? Si oui, notification initiale sous 4 heures à compter de la classification, rapport intermédiaire sous 72 heures, rapport final sous 1 mois. Les trois régimes peuvent se cumuler. La décision se documente dans une fiche de classification écrite, avec horodatage.

Comment forcer un reset de mots de passe et MFA sur un grand parc ? L’opération s’exécute depuis l’IdP central (Entra ID, Okta, Google Workspace, Keycloak) via une commande de bulk reset ciblée sur le périmètre identifié. Trois étapes : révocation des sessions actives et tokens OAuth, expiration forcée des mots de passe avec changement obligatoire à la prochaine connexion, ré-enrôlement MFA pour les comptes compromis (les facteurs FIDO2 ou passkeys sont préservés, les facteurs SMS et OTP sont à reconfigurer). Pour les comptes à privilèges, ajouter une rotation des secrets applicatifs (clés d’API, certificats, tokens de service) et un contrôle de la base d’inventaire des secrets (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault).

Comment communiquer aux utilisateurs et clients impactés sans aggraver l’incident ? La communication suit trois principes : factuelle, calibrée par audience, validée par le juridique avant diffusion. Aux collaborateurs concernés, message direct avec instructions opérationnelles (changer le mot de passe, ré-enrôler MFA, signaler toute activité anormale), sans détail technique sur la chaîne d’attaque. Aux clients impactés, courrier ou email mentionnant les faits, le périmètre, les mesures prises, les actions recommandées et un point de contact. Aux médias et au public, communication dimensionnée au risque réputationnel et coordonnée avec la cellule de crise. Éviter toute communication avant H+12 sauf obligation réglementaire ou découverte par un tiers (média, fournisseur).

Quel post-mortem produire après les 72 heures ? Un post-mortem structuré, sans recherche de coupable, livré dans un délai de 2 à 4 semaines après la résolution. Il couvre : chronologie horodatée des événements de la détection à la remédiation, cause racine technique et organisationnelle, périmètre exact (comptes, systèmes, données), mesures correctives engagées avec responsable et date de clôture, axes d’amélioration sur la détection, la classification, la mobilisation et la communication, indicateurs (MTTD, MTTR, durée d’exposition). Le post-mortem est présenté au COMEX ou au comité sécurité, archivé dans le registre d’incidents, et alimente le programme d’exercices de l’année suivante. Il est aussi un livrable attendu par les superviseurs (CNIL, ANSSI, ACPR) en cas d’audit.

Pour aller plus loin

• DORA : guide de conformité cybersécurité pour le secteur financier : détail des délais 4h/24h/1 mois et des seuils de classification d’incident majeur.
• Comment détecter une fuite d’identifiants ? : méthodes manuelles et automatisées pour alimenter le H+0 du playbook.
• Glossaire SIEM : vocabulaire de référence pour les corrélations et l’investigation forensic.
• Cyber Threat Intelligence : guide complet : structurer la veille externe pour réduire le délai de détection.
• NIST SP 800-61 rev 2 - Computer Security Incident Handling Guide : référence méthodologique internationale.
• ANSSI - Anticiper et gérer une crise cyber : guide opérationnel pour les organisations françaises.
• CNIL - Violations de données personnelles : les règles à suivre : procédure de notification CNIL.
• ENISA - Good Practice Guide for Incident Management : bonnes pratiques européennes pour les CERT et CSIRT.