← Tous les articles

ARTICLE · DATA LEAK ACTIVE TESTING

Réponse à incident fuite de données : les 24 premières heures

  • Méthode
  • 6 min de lecture
  • Mis à jour le
Arête d'un triangle d'alerte rouge au-dessus d'un circuit électronique, image d'un incident à contenir72 h pour notifier, 24 h pour préparer

L’essentiel en 30 secondes

  • Les 24 premières heures servent à qualifier ce qui est sorti, contenir le canal, préserver les preuves et préparer la notification.
  • Le délai de 72 heures du RGPD court à partir de la prise de connaissance : horodatez l’ouverture de l’incident, notifiez par étapes si besoin.
  • Chaque constat du retour d’expérience devient un scénario rejoué avec des données factices, pour prouver que la correction tient.

La réponse à incident après une fuite de données se joue dans les 24 premières heures : qualifier ce qui est sorti, contenir le canal d’exfiltration, préserver les preuves et préparer la notification. Si des données personnelles sont concernées, le RGPD (article 33) impose de notifier la CNIL dans les 72 heures après en avoir pris connaissance, sauf si la violation ne présente pas de risque pour les personnes. Les 24 premières heures servent donc à rendre cette notification possible et juste.

Cet article décrit un déroulé heure par heure, côté défenseur, puis montre comment transformer le retour d’expérience en tests rejouables. Pour le cadre général du test d’exfiltration, voyez notre page Test d’exfiltration de données : définition, méthode et enjeux.

Pourquoi l’exfiltration change la nature de l’incident

Un poste chiffré par un rançongiciel se voit. Une exfiltration, non. Elle est souvent découverte tard, par un tiers, une alerte de volumétrie ou une revendication publique. Le premier réflexe des équipes est de chercher le malware. C’est une erreur de priorité. La question qui compte est : quelles données ont quitté le périmètre, par quel canal, et le canal est-il encore ouvert ?

Dans les attaques à double extorsion, l’exfiltration précède le chiffrement et sert de levier de chantage. Le sujet est développé dans Ransomware et double extorsion : l’exfiltration est l’étape à tester.

Le déroulé des 24 premières heures

Schéma · les 24 premières heures

Les 24 premières heures en quatre tempsDe H0 à H2, déclarer et horodater l’incident. De H2 à H6, contenir le canal de sortie. De H6 à H12, qualifier ce qui est sorti. De H12 à H24, évaluer le risque pour les personnes. Le tout prépare la notification à la CNIL, attendue sous 72 heures.H0 à H2Déclarer,horodaterH2 à H6Contenirle canalH6 à H12Qualifierla sortieH12 à H24Évaluerle risquePréparer la notification sous 72 h

H0 à H2 : déclarer et horodater

  • Ouvrir l’incident formellement avec une heure de prise de connaissance écrite. C’est elle qui fait courir le délai de 72 heures, pas l’heure de l’attaque.
  • Constituer la cellule restreinte : RSSI ou responsable SOC, DPO, DSI, juridique, communication en veille. Un seul responsable du journal de bord.
  • Choisir un canal de communication hors bande si la messagerie ou l’annuaire sont potentiellement compromis.
  • Prévenir l’assureur cyber si le contrat l’exige dans un délai court.

H2 à H6 : contenir sans détruire les preuves

Le confinement vise le canal de sortie avant tout. Bloquer les destinations identifiées au niveau du proxy et du pare-feu, révoquer les jetons et sessions des comptes suspects, isoler les postes concernés du réseau sans les éteindre. Éteindre une machine efface la mémoire vive, souvent la seule trace utile.

H6 à H12 : qualifier ce qui est sorti

Le SOC reconstitue la chronologie à partir des journaux : proxy, DNS, pare-feu, journaux d’audit SaaS, agents endpoint, passerelle de messagerie. Trois questions structurent le travail :

  1. Quoi : quelles catégories de données (personnelles, de santé, secrets d’affaires, données clients) et quel volume approximatif.
  2. Comment : quel canal (HTTPS vers un stockage cloud, DNS, messagerie, support amovible, outil collaboratif).
  3. Depuis quand : la première sortie connue, souvent bien antérieure à la détection.

Si la classification des données est absente, cette étape devient un travail d’archéologie. Le lien entre les deux est expliqué dans Pourquoi la DLP dépend de la classification des données. Pour la méthode de détection elle-même, voyez Détecter l’exfiltration : méthode pour le SOC et délai de détection.

H12 à H24 : évaluer le risque et préparer la notification

Le DPO évalue le risque pour les personnes concernées : nature des données, volume, possibilité d’identification, conséquences possibles. Cette évaluation conditionne la suite.

Ce que le RGPD exige, et ce qu’il n’exige pas

Obligation Texte Délai ou condition
Notifier la CNIL RGPD, article 33 Dans les meilleurs délais et si possible 72 heures au plus tard après en avoir pris connaissance, sauf si la violation est peu susceptible d’engendrer un risque pour les droits et libertés des personnes
Justifier un retard RGPD, article 33 Une notification au-delà de 72 heures doit être accompagnée des motifs du retard
Notifier par étapes RGPD, article 33 Les informations peuvent être communiquées de manière échelonnée si tout n’est pas connu
Informer les personnes RGPD, article 34 Lorsque la violation est susceptible d’engendrer un risque élevé
Documenter toute violation RGPD, article 33 Registre interne, y compris pour les violations non notifiées

Point pratique : la notification par étapes est votre alliée. Ne retardez pas la déclaration initiale dans l’attente d’une qualification parfaite. Une notification initiale à H48 avec des compléments ensuite vaut mieux qu’une notification exhaustive à H90. La CNIL propose un téléservice dédié. Un sous-traitant, lui, doit prévenir le responsable de traitement dans les meilleurs délais : si la fuite survient chez un prestataire, voyez Fuites de données chez les tiers et sous-traitants.

Selon votre secteur, d’autres régimes peuvent s’ajouter (NIS2, DORA pour les entités financières), avec leurs propres délais et autorités. Vérifiez-les dans votre plan de réponse avant l’incident, pas pendant.

Scénario concret : un export CRM vers un stockage personnel

Mardi, 16 h. Une alerte de volumétrie signale un envoi inhabituel depuis le poste d’un commercial vers un service de stockage grand public. Le SOC confirme l’envoi d’un export CRM contenant noms, e-mails et téléphones de clients.

  • 16 h 30 : incident ouvert, heure de prise de connaissance consignée.
  • 18 h : session du compte révoquée, domaine de stockage bloqué pour ce poste, poste isolé.
  • Mercredi 10 h : chronologie établie, une seule sortie identifiée, catégories de données connues.
  • Mercredi 15 h : le DPO conclut à un risque pour les personnes, préparation de la notification initiale.

La vraie question du retour d’expérience arrive ensuite : pourquoi la règle DLP censée bloquer ce type de fichier vers un cloud personnel n’a-t-elle rien fait ? Ce cas est typique des fuites du quotidien décrites dans Cloud personnel, Teams, Slack : les fuites de données du quotidien.

Et chez vous ?

Votre dernier incident est-il devenu un test rejoué ?

Une démo guidée de 30 minutes, sur des jeux de résultats préétablis, pour voir comment une campagne restitue ce qui sort par chaque chemin de sortie.

Du retour d’expérience aux tests

Un retour d’expérience classique produit un document. Il est lu une fois, puis oublié. La méthode plus utile consiste à convertir chaque constat en scénario d’attaque rejouable, avec des données factices.

Les points de conversion

  • Le canal utilisé est décrit comme un scénario testable (type de donnée, canal, destination, contexte utilisateur).
  • La correction apportée a une attente vérifiable : bloqué, alerté, ou journalisé.
  • Le scénario est rejoué juste après la correction, pour prouver qu’elle fonctionne.
  • Il est rejoué ensuite à intervalle régulier, car une mise à jour d’agent ou de politique peut le casser en silence.
  • Les variantes proches du canal (autre format, autre service, autre poste) sont ajoutées au jeu de tests.
  • Les résultats alimentent un indicateur suivi dans le temps, pas une case cochée.

FAQ

Le délai de 72 heures part-il de l’attaque ou de la détection ?

Du moment où le responsable de traitement prend connaissance de la violation. D’où l’importance d’horodater l’ouverture de l’incident et de documenter les étapes de qualification.

Faut-il notifier la CNIL si les données exfiltrées étaient chiffrées ?

Pas forcément. Si la violation est peu susceptible d’engendrer un risque, par exemple parce que les données sont inintelligibles et la clé non compromise, la notification peut ne pas être requise. La violation doit tout de même être documentée en interne.

Que faire si l’on ne sait pas encore ce qui a été volé à H72 ?

Notifier avec les informations disponibles, puis compléter. Le RGPD prévoit explicitement une communication échelonnée.

Faut-il éteindre les machines compromises ?

En règle générale, non : isolez-les du réseau. L’extinction détruit des traces en mémoire utiles pour comprendre le canal d’exfiltration.

Ce qui sort réellement par vos chemins de sortie, mesuré.

Un incident révèle un contrôle qui ne fonctionnait pas. Nous rejouons, avec des données synthétiques et à travers vos vrais contrôles de sortie, des scénarios d’exfiltration contrôlés mappés à MITRE ATT&CK, et nous restituons pour chacun ce qui a été tenté, transmis et collecté. Les constats sont ensuite analysés avec vous pour prioriser les corrections. Le scénario tiré de l’incident se rejoue ensuite à la demande, pour vérifier dans la durée que la correction tient.