Gérer un incident de cybersécurité : réponse, preuves et obligations

Un incident de sécurité est un événement qui porte atteinte, ou menace de porter atteinte, à la disponibilité, l'intégrité ou la confidentialité du système d'information : intrusion, rançongiciel, fuite de données, compte piraté. Le gérer, c'est le qualifier, le contenir, l'éradiquer, rétablir le service, puis en tirer les leçons, tout en préservant les preuves et en respectant les obligations légales (notification à la CNIL, plainte, déclaration à l'assureur). Ce chapitre donne la méthode, les bons réflexes des premières minutes, les règles de la preuve numérique et les obligations qui s'imposent à l'organisation. Il se termine par une étude de cas qui mobilise tout le cours.

Événement, incident, crise

• Un événement est un fait observable : une alerte de l'IDS, un échec de connexion, un port qui tombe. La plupart sont sans gravité.
• Un incident est un événement qualifié comme une atteinte réelle ou probable à la sécurité : l'alerte est un vrai positif, le compte a bien été piraté.
• Une crise est un incident dont l'ampleur dépasse la gestion courante : l'activité est arrêtée, la direction pilote, la communication externe est en jeu.

Un incident de sécurité se traite comme tout incident dans l'outil de ticketing, avec une priorité issue de la matrice impact × urgence d'ITIL (cours ITIL). Cette priorité se réévalue quand la situation change : un ralentissement qui touchait un service (P2) devient un blocage de toute l'activité (P1). C'est la question A1.4 du sujet E7 SISR 2025.

Les phases de la réponse à incident

Le cadre le plus cité vient du NIST, l'institut de normalisation américain (publication SP 800-61, dont la révision de 2025 s'aligne sur son cadre de cybersécurité). Ses étapes classiques, reprises par l'ANSSI et les CSIRT, structurent toutes les procédures :

Les bons réflexes des premières minutes

Les fiches du CERT-FR et de Cybermalveillance.gouv.fr donnent les mêmes consignes, qu'il faut connaître par cœur :

1. Isoler la machine suspecte du réseau : débrancher le câble réseau, couper le Wi-Fi. C'est le geste qui empêche la propagation.
2. Ne pas l'éteindre ni la redémarrer : la mémoire vive contient des traces précieuses (processus, connexions, parfois des clés de chiffrement) qui disparaissent à l'arrêt. Exception : si le chiffrement est en cours et que l'isolement est impossible, couper peut limiter les dégâts.
3. Alerter son responsable, le référent sécurité, le prestataire : jamais seul, jamais en silence.
4. Ne rien effacer, ne pas réinstaller dans la précipitation : ce serait détruire les preuves et la possibilité de comprendre.
5. Noter tout ce qui est observé et fait, avec l'heure, dans une main courante : qui, quoi, quand.
6. Communiquer par un canal sûr : si la messagerie ou l'annuaire sont compromis, l'attaquant peut lire les échanges de l'équipe. Téléphone, messagerie de secours.
7. Ne pas payer de rançon : rien ne garantit la récupération des données, et le paiement finance de nouvelles attaques. L'ANSSI le déconseille fermement.
8. Se faire aider : le numéro 17Cyber et Cybermalveillance.gouv.fr orientent les victimes et proposent des prestataires labellisés ; les CSIRT régionaux accompagnent les PME et les collectivités ; le CERT-FR intervient pour les incidents graves des administrations et des opérateurs critiques.

La preuve numérique

Si l'organisation veut porter plainte, se faire indemniser par son assureur ou simplement comprendre l'attaque, elle doit préserver les preuves. Une preuve numérique est fragile : elle s'efface, s'écrase, se modifie à la moindre manipulation.

L'ordre de volatilité. On collecte d'abord ce qui disparaît le plus vite (recommandation de la RFC 3227) :

1. la mémoire vive, les processus en cours, les connexions réseau ouvertes ;
2. les fichiers temporaires ;
3. le disque ;
4. les journaux distants (pare-feu, SIEM, proxy) ;
5. les sauvegardes et les archives.

Les règles de collecte.

• Faire une copie bit à bit du disque (image), avec un bloqueur d'écriture, et travailler sur la copie, jamais sur l'original.
• Calculer l'empreinte (SHA-256) de l'image au moment de la copie et la noter : la recalculer plus tard prouve que la copie n'a pas changé (chapitre 6).
• Tenir la chaîne de possession (chain of custody) : pour chaque élément, qui l'a collecté, quand, où il a été stocké, qui y a eu accès.
• Conserver les journaux centralisés de la période, horodatés de façon fiable (NTP).
• Pour un constat opposable, faire appel à un commissaire de justice (anciennement huissier) ou à un prestataire spécialisé.

Éradiquer et rétablir

• Comprendre avant de nettoyer : par où l'attaquant est entré, quels comptes il a utilisés, quelles machines il a touchées. Nettoyer une machine sans fermer la porte d'entrée, c'est le voir revenir le lendemain.
• Reconstruire plutôt que réparer les machines compromises : réinstallation depuis des sources saines, puis restauration des données.
• Réinitialiser les secrets : mots de passe des comptes touchés, de tous les comptes d'administration, des comptes de service, clés VPN et certificats exposés. Après une compromission d'Active Directory, le mot de passe du compte krbtgt (qui signe les tickets Kerberos) est réinitialisé deux fois, à intervalle, pour invalider tous les tickets forgés.
• Corriger la faille exploitée (mise à jour, configuration), sur toutes les machines concernées.
• Restaurer depuis une sauvegarde antérieure à la compromission, vérifiée saine, puis remettre en service progressivement en surveillant de près.

Tout cela suppose des sauvegardes qui ont survécu à l'attaque. Les recommandations de l'ANSSI sur les sauvegardes, que le sujet 2026 demande de vérifier une à une :

La démarche complète (PRA, PCA, durée maximale d'interruption et perte de données admissibles) est dans le cours Sauvegarde et PRA.

Les obligations légales

Le sujet 2026 demande si un incident « entraîne des obligations légales pour l'entreprise » (question A2.2). Raisonne en trois temps : y a-t-il des données personnelles touchées ? L'organisation est-elle soumise à une réglementation sectorielle ? Veut-elle porter plainte ou être indemnisée ?

Violation de données personnelles (RGPD). Une violation, c'est la destruction, la perte, l'altération, la divulgation ou l'accès non autorisé à des données personnelles, accidentel ou illicite. Un rançongiciel qui chiffre un serveur de fichiers contenant des fiches de salariés en est une (atteinte à la disponibilité), même sans vol.

Un sous-traitant (l'hébergeur, le prestataire) qui constate une violation doit prévenir le responsable de traitement dans les meilleurs délais ; c'est le responsable de traitement qui notifie la CNIL (cours Droit et RGPD).

Plainte et assurance. L'organisation victime peut porter plainte auprès de la police, de la gendarmerie ou du procureur de la République. Les atteintes aux systèmes de traitement automatisé de données sont punies par le Code pénal : accès ou maintien frauduleux (article 323-1, jusqu'à trois ans d'emprisonnement et 100 000 € d'amende), entrave au fonctionnement (323-2) et introduction, modification ou suppression frauduleuse de données (323-3), jusqu'à cinq ans et 150 000 €. Pour être indemnisée par son assurance cyber, la victime doit avoir déposé plainte dans les 72 heures après avoir pris connaissance de l'attaque (article L12-10-1 du Code des assurances, issu de la loi du 24 janvier 2023).

Réglementations sectorielles. Les opérateurs d'importance vitale (OIV) et les opérateurs de services essentiels déclarent leurs incidents à l'ANSSI. La directive européenne NIS 2 étend cette obligation à des milliers d'entités « essentielles » et « importantes » (santé, énergie, transport, collectivités, numérique, industrie…), avec une alerte précoce sous 24 heures, une notification sous 72 heures et un rapport final sous un mois ; sa transposition en droit français, par le projet de loi relatif à la résilience des infrastructures critiques, n'était pas encore définitivement adoptée à l'automne 2026 (adoptée par le Sénat, en discussion à l'Assemblée nationale) : vérifie son statut sur Légifrance. Une entreprise de transport comme Sorbier pourrait être concernée selon sa taille : la vérification fait partie de la réponse.

Communiquer pendant l'incident

• En interne : la direction décide et arbitre (arrêt d'un service, appel à un prestataire, dépôt de plainte) ; les salariés reçoivent des consignes simples (ne pas rallumer les postes, ne pas utiliser la messagerie).
• En externe : clients, partenaires, éventuellement presse. Un seul porte-parole, des faits vérifiés, pas de spéculation. Un client dont les données sont touchées doit l'apprendre par l'organisation, pas par les journaux.
• Avec les autorités : CNIL, forces de l'ordre, ANSSI ou CSIRT selon le cas, assureur.

Le retour d'expérience

Une fois le service rétabli, l'équipe rédige le retour d'expérience (RETEX) : la chronologie complète, la cause racine (la faille, mais aussi pourquoi elle n'était pas corrigée), ce qui a fonctionné, ce qui a manqué, et un plan d'actions daté avec un responsable pour chaque action. C'est l'équivalent, pour la sécurité, de la gestion des problèmes d'ITIL (cours ITIL). Le compte rendu doit être « clair et explicite », et les contre-mesures « documentées de manière à en assurer le suivi » : ce sont les termes du référentiel.

Pour aller plus loin. Le cours Journalisation et réponse à incident déroule les six phases de la réponse, la collecte des preuves et les notifications obligatoires ; le cours Épreuve E7 SISR entraîne à ces questions sur des sujets complets.

Exercices

Exercice 1 sur 5 Réévaluer la priorité Réussi À revoir

Avec la matrice ITIL suivante, un incident a été classé P2 à 9 h : « lenteurs sur le réseau des postes, plusieurs utilisateurs gênés, travail possible ». À 10 h, plus aucun service ne peut utiliser le réseau et toute l'activité est bloquée.

Impact \ Urgence	Haute	Moyenne	Basse
Fort	P1	P2	P3
Moyen	P2	P3	P4
Faible	P3	P4	P5

1. Justifie le classement P2 de 9 h.
2. Réévalue la priorité à 10 h.

Voir la réponseMasquer la réponse de l'exercice 1

1. À 9 h : impact moyen (un groupe d'utilisateurs, le travail reste possible) et urgence haute (la situation se dégrade), ou impact fort et urgence moyenne : les deux donnent P2.
2. À 10 h : impact fort (toute l'organisation, activité bloquée) et urgence haute (aucun contournement, perte d'activité à chaque minute) : P1, critique. Il faut mobiliser immédiatement les ressources, prévenir la direction et appliquer les délais de prise en charge les plus courts.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 2 sur 5 Les premiers gestes Réussi À revoir

À 8 h 30, une comptable appelle : ses fichiers ont tous une extension inconnue et un fichier « LISEZ-MOI » réclame une rançon. Classe ces actions dans l'ordre où tu les fais, et barre celles qu'il ne faut pas faire : éteindre le poste ; débrancher le câble réseau du poste ; prévenir le responsable et le référent sécurité ; payer la rançon pour aller vite ; noter l'heure et les constats ; réinstaller le poste immédiatement ; vérifier si d'autres postes ou serveurs sont touchés ; supprimer le fichier de rançon.

Voir la réponseMasquer la réponse de l'exercice 2

Dans l'ordre :

1. Débrancher le câble réseau (et couper le Wi-Fi) : stopper la propagation vers les partages et les autres machines.
2. Noter l'heure et les constats (main courante), photographier l'écran.
3. Prévenir le responsable et le référent sécurité.
4. Vérifier si d'autres machines sont touchées (serveur de fichiers, autres postes, alertes de l'EDR et du SIEM), et les isoler si besoin.

À ne pas faire : éteindre le poste (perte des traces en mémoire, sauf si le chiffrement se poursuit et qu'on ne peut pas l'isoler) ; payer la rançon (aucune garantie, financement des attaquants, déconseillé par l'ANSSI) ; réinstaller immédiatement (destruction des preuves, et la cause n'est pas comprise) ; supprimer le fichier de rançon (c'est un élément de preuve qui identifie souvent le rançongiciel).

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 3 sur 5 Pourquoi l'enquête est difficile Réussi À revoir

Après une intrusion, le prestataire chargé de l'analyse signale : « Les serveurs ont été restaurés à partir des sauvegardes avant notre arrivée ; les journaux étaient conservés seulement sur chaque serveur, sur sept jours ; l'horloge du pare-feu avait 14 minutes d'avance. » Pour chaque élément, explique en quoi il gêne l'investigation, et ce qu'il aurait fallu faire.

Voir la réponseMasquer la réponse de l'exercice 3

• Restauration avant analyse : l'état des machines au moment de l'attaque (mémoire, fichiers déposés, comptes créés) a été écrasé. Il fallait isoler les machines, faire une copie (image et mémoire) avec calcul d'empreinte, puis seulement restaurer.
• Journaux locaux sur sept jours : si l'intrusion a commencé plus tôt, ses traces ont disparu ; l'attaquant a aussi pu effacer les journaux de chaque serveur. Il fallait centraliser les journaux en temps réel sur un serveur protégé, avec une durée de conservation de six mois à un an.
• 14 minutes d'écart : la chronologie entre le pare-feu et les serveurs est faussée, les corrélations deviennent incertaines. Il fallait synchroniser toutes les machines par NTP sur la même source.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 4 sur 5 Quelles obligations ? Réussi À revoir

Un rançongiciel a chiffré le serveur de fichiers de Sorbier pendant le week-end. Le serveur contient les fiches du personnel (identité, adresse, numéro de sécurité sociale, coordonnées bancaires). Les journaux montrent que 3 Go ont été envoyés vers l'extérieur avant le chiffrement. Sorbier a une assurance cyber. Les sauvegardes hors ligne permettent de tout restaurer. Quelles sont ses obligations, et dans quels délais ?

Voir la réponseMasquer la réponse de l'exercice 4

• Registre des violations : la violation est inscrite dans le registre interne (article 33.5 du RGPD), dans tous les cas.
• Notification à la CNIL sous 72 heures après la prise de connaissance (article 33) : il y a un risque pour les personnes, puisque des données sont devenues indisponibles et ont probablement été copiées. La restauration ne supprime pas l'obligation : la fuite reste.
• Information des salariés concernés (article 34) : le risque est élevé (numéro de sécurité sociale, coordonnées bancaires, risque d'usurpation d'identité et de fraude), il faut les informer dans les meilleurs délais, avec les précautions à prendre (vigilance sur les courriels, surveillance des comptes bancaires).
• Plainte dans les 72 heures pour pouvoir être indemnisée par l'assurance (article L12-10-1 du Code des assurances), et déclaration à l'assureur selon le contrat.
• Vérifier si Sorbier entre dans le champ de NIS 2 ou d'une réglementation sectorielle, qui imposerait une déclaration à l'ANSSI.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Étude de cas : l'intrusion chez Sorbier

Exercice 5 sur 5 Étude de cas complète Réussi À revoir

Un lundi à 7 h 50, le SOC du prestataire de Sorbier transmet trois alertes de la nuit :

• 02:14 : l'IDS de l'interface DMZ signale une tentative d'exploitation d'une faille connue de l'application de suivi des livraisons, depuis 198.51.100.66 ;
• 02:31 : le pare-feu refuse 240 connexions de 192.168.10.225 (srv-web) vers 192.168.10.176/28 sur les ports 445 et 3389 ;
• 02:47 : le pare-feu refuse des connexions de 192.168.10.225 vers 198.51.100.66 sur le port 4444.

L'éditeur de l'application a publié un correctif il y a cinq semaines ; il n'a pas été installé. Le site de suivi est toujours en ligne.

1. Reconstitue l'attaque en trois étapes et associe chacune à une étape du chapitre 1 (préparer, entrer, s'installer, s'étendre, agir).
2. L'attaquant a-t-il atteint le réseau interne ? Quels mécanismes de ce cours l'en ont empêché ?
3. Quels critères DICP sont menacés, et pour quelles données ?
4. Donne l'action d'urgence, puis trois mesures de remédiation durable.
5. Quelles preuves faut-il préserver, et comment ?
6. Y a-t-il une obligation de notification à la CNIL ?

Voir la réponseMasquer la réponse de l'exercice 5

1. Entrer : à 02:14, exploitation d'une faille connue du site exposé (technique Exploit Public-Facing Application), probablement réussie puisque la suite vient du serveur lui-même. S'étendre : à 02:31, srv-web tente SMB et RDP vers tous les serveurs internes, une tentative de mouvement latéral. Agir (commande et contrôle) : à 02:47, srv-web tente de rappeler l'adresse de l'attaquant sur le port 4444, pour recevoir des ordres.
2. Non, selon les journaux : toutes les connexions vers l'intérieur et vers l'attaquant ont été refusées. La DMZ (chapitre 3) n'autorise srv-web qu'à joindre l'API de srv-gestion sur TCP 8443 et à envoyer ses journaux à srv-journaux ; le filtrage sortant n'autorise que DNS et les mises à jour ; la journalisation des refus et l'IDS ont permis la détection. Il faut vérifier l'API sur le port 8443, seul flux autorisé qui donne accès à des données métier, dans les journaux de srv-gestion.
3. Intégrité et disponibilité du site de suivi (serveur compromis, contenu modifiable, service à couper) ; confidentialité des données du site (noms et adresses de livraison des clients, données personnelles) et des données que srv-web peut lire par l'API.
4. Action d'urgence : isoler srv-web (bloquer tous ses flux sur le pare-feu, ou le déconnecter du réseau) sans l'éteindre, et mettre le site hors ligne avec une page d'information. Remédiation durable : reconstruire srv-web depuis une image saine avec le correctif de l'application installé ; réinitialiser tous les secrets présents sur le serveur (clé de l'API, mots de passe, clé privée du certificat, à révoquer) ; mettre en place une veille et un délai maximal d'installation des correctifs critiques pour les services exposés ; ajouter un proxy inverse avec pare-feu applicatif devant le site.
5. Copie de la mémoire et image du disque de srv-web avant toute réinstallation, avec empreinte SHA-256 et chaîne de possession ; export des journaux du pare-feu, de l'IDS, du serveur web et de srv-gestion pour la période, depuis le serveur central ; main courante horodatée de toutes les actions.
6. Il faut d'abord documenter l'incident dans le registre des violations. Si l'analyse montre que les données personnelles des clients du site ont pu être consultées ou copiées par l'attaquant, il y a un risque pour les personnes : notification à la CNIL sous 72 heures après la prise de connaissance, quitte à la compléter ensuite. Si l'analyse établit que l'attaquant n'a eu accès à aucune donnée personnelle, l'inscription au registre suffit, avec la justification. Dans le doute, on notifie dans les délais.

Tu avais trouvé ?

Oui, j'avais bonPas encore