Votre application a été attaquée : les premières heures, puis la remise en sécurité

Quel type d'attaque avez-vous subi ?

Les premiers gestes dépendent de ce qui s'est passé. Sur une application métier ou une plateforme, les situations les plus courantes ne demandent pas la même réaction :

Les premières heures : quels sont les réflexes officiels ?

Les réflexes officiels tiennent en cinq gestes, dont trois sont encadrés par des délais.

1. Isoler sans effacer. La CNIL recommande de débrancher le câble réseau ou de couper le Wi-Fi de la machine touchée, de ne pas l'éteindre afin de conserver les preuves, et de ne pas payer de rançon. Pour une application hébergée, cela revient à couper l'accès public plutôt qu'à supprimer le serveur.
2. Demander de l'aide. 17Cyber est un service gratuit d'assistance en ligne, accessible à toute heure, opéré par la Police nationale, la Gendarmerie nationale et Cybermalveillance.gouv.fr. Selon la Gendarmerie nationale, il s'adresse aussi aux entreprises : un diagnostic en ligne qualifie la menace, puis le service oriente vers les démarches utiles ou vers des experts, ce dernier accompagnement étant payant.
3. Porter plainte. La Gendarmerie nationale rappelle que, depuis le 24 avril 2023, une entreprise victime d'une cyberattaque dans un cadre professionnel doit déposer plainte dans les 72 heures suivant la connaissance de l'attaque pour être indemnisée par son assureur.
4. Notifier la CNIL si des données personnelles sont touchées. L'article 33 du RGPD impose une notification « dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance », sauf absence de risque pour les personnes. Le téléservice de la CNIL accepte une notification initiale, complétée ensuite, et toute violation doit être documentée en interne, même non notifiée. En cas de risque élevé, l'article 34 impose d'informer les personnes concernées dans les meilleurs délais ; nos repères sur le RGPD dans un logiciel métier complètent ce point.
5. Prévenir l'assureur, l'hébergeur et les éditeurs des services touchés.

Que faut-il éviter dans l'urgence ?

Dans l'urgence, il faut surtout éviter les gestes qui détruisent les preuves ou rouvrent la porte à l'attaquant :

• restaurer une sauvegarde par-dessus le serveur attaqué, ce qui efface les traces de l'intrusion ;
• remettre l'application en ligne avant d'avoir trouvé le point d'entrée : l'attaquant reviendra par le même chemin ;
• modifier les réglages sans noter quoi, ni à quelle heure ;
• communiquer publiquement avant de connaître l'étendue de l'incident ;
• supposer qu'une sauvegarde est saine sans vérifier sa date et son contenu.

Tenez dès la première minute une main courante horodatée : qui a constaté quoi, quelles actions ont été menées. Elle servira pour la plainte, pour l'assureur et pour la CNIL.

Comment trouver par où l'attaquant est entré ?

L'analyse reconstitue une chronologie à partir des traces disponibles : journaux du serveur, de l'application et de la base de données, historique des connexions administrateur, journaux de l'hébergeur. Les questions sont toujours les mêmes : quel compte ou quelle faille a servi d'entrée, à quoi l'attaquant a-t-il eu accès, depuis quand, et a-t-il laissé un moyen de revenir (compte créé, fichier déposé, clé ajoutée) ?

Sur une application, les points d'entrée les plus courants sont connus : mot de passe administrateur réutilisé ou divulgué, bibliothèque comportant une faille publiée et jamais mise à jour, formulaire qui accepte des commandes à la place de données, fichier déposé par un utilisateur puis exécuté sur le serveur, clé d'API écrite en clair dans le code. Sans journaux, l'analyse devient une enquête par recoupements : c'est souvent la première leçon de l'incident.

Corriger, puis durcir : que change-t-on dans l'application ?

On corrige d'abord la faille exploitée, puis on durcit l'application pour que la même famille de failles ne puisse plus servir.

Pour les sauvegardes, la CNIL recommande trois copies, sur deux supports différents, dont une déconnectée du réseau, et de tester régulièrement la restauration. Les bases sont détaillées dans notre guide pour sécuriser une application métier. Une fois les correctifs en place, un test d'intrusion mené par un tiers vérifie que les portes sont réellement fermées.

Comment surveiller pour ne pas revivre l'incident ?

La surveillance repose sur des journaux conservés hors du serveur applicatif et sur quelques alertes simples : connexion administrateur à une heure inhabituelle, export massif de données, pic d'échecs d'authentification, création d'un compte à privilèges. La CNIL rappelle que les attaquants exploitent souvent des failles connues, généralement déjà corrigées par les éditeurs : appliquer les mises à jour fait partie de la surveillance.

La préparation compte autant. Cybermalveillance.gouv.fr propose SenCy-Crise, un parcours en ligne gratuit d'initiation à la gestion de crise cyber destiné notamment aux PME, aux associations et aux collectivités, organisé en trois modules : avant, pendant et après la crise. Si votre entreprise entre dans le champ de la directive NIS 2, d'autres obligations s'ajoutent ; notre guide NIS 2 pour les PME aide à le vérifier.

Ce que YMHB Web fait concrètement après un incident

YMHB Web dispose de compétences internes en cybersécurité, dont la veille sur les menaces (Cyber Threat Intelligence), qu'elle met au service de la partie applicative : récupération des accès, analyse du code et des journaux de l'application, correctifs, durcissement, remise en service par étapes et mise en place de la surveillance. Nous travaillons en lien avec votre assureur, votre hébergeur et, s'il y en a un, le prestataire qui traite le reste du système d'information.

À la fin, vous recevez un rapport qui décrit la chronologie établie, les failles trouvées, les corrections apportées et les points encore ouverts. Le code corrigé reste déposé sur vos comptes.

Ce qui ne relève pas d'un développeur

Une partie de la réponse à un incident ne relève ni d'un développeur ni d'un logiciel sur mesure.

• L'investigation de tout le système d'information (postes, messagerie, annuaire) relève d'un prestataire de réponse aux incidents ; l'ANSSI publie un référentiel d'exigences pour qualifier ces prestataires de réponse aux incidents de sécurité, dits PRIS.
• L'assistance de proximité : Cybermalveillance.gouv.fr met en relation les professionnels avec des prestataires labellisés ExpertCyber, un label délivré à l'issue d'un audit réalisé par AFNOR Certification.
• Le volet juridique : responsabilité envers les clients, contrats et échanges avec l'assureur relèvent de votre avocat.
• La communication de crise auprès des clients et du public, si l'incident devient visible.