Réagir à un incident de sécurité : la procédure simple pour une petite équipe

Un incident de sécurité ne se résume pas toujours à une attaque spectaculaire. Un mot de passe réutilisé, une boîte mail consultée depuis un appareil inconnu, un site WordPress modifié ou un fichier devenu illisible peuvent déjà nécessiter une réaction organisée. Dans les premières heures, l’objectif n’est pas de trouver immédiatement l’origine exacte du problème : il faut limiter les dégâts, préserver les informations utiles et rétablir un fonctionnement fiable.

Une petite entreprise ou un indépendant peut préparer cette réponse sans disposer d’un centre opérationnel de sécurité. Une procédure courte, connue à l’avance et adaptée à ses outils évite les décisions improvisées. Elle doit préciser qui alerter, quoi isoler, quelles preuves conserver et dans quel ordre restaurer les services.

Reconnaître un incident sans attendre une certitude absolue

Un signal isolé peut être une erreur technique. Plusieurs signaux concordants doivent toutefois être traités comme un incident potentiel, surtout lorsqu’ils concernent un compte administrateur, un moyen de paiement ou des données clients.

• Une connexion apparaît depuis un lieu ou un appareil inhabituel.
• Un mot de passe ne fonctionne plus alors que personne ne l’a modifié volontairement.
• Des messages sont envoyés depuis une boîte mail sans l’intervention de son propriétaire.
• Des fichiers ont été renommés, supprimés ou rendus inaccessibles.
• Un site affiche un contenu inconnu, redirige les visiteurs ou signale une activité suspecte.
• Un outil demande soudainement un paiement, une validation ou une nouvelle autorisation.
• Un prestataire, un client ou un collaborateur signale un message étrange provenant de l’organisation.

À ce stade, évitez les conclusions trop rapides. Un compte compromis n’implique pas nécessairement que tout le système est infecté, mais il faut agir comme si l’accès pouvait être utilisé tant qu’il n’est pas sécurisé. Notez l’heure de la découverte, la personne qui a constaté le problème et les éléments visibles à l’écran.

Les premières minutes : contenir sans détruire les indices

La priorité immédiate est de réduire la capacité d’action de l’attaquant ou de limiter la propagation. Les mesures exactes dépendent du service touché, mais quatre réflexes sont généralement utiles.

Isoler l’équipement ou le compte concerné

Si un ordinateur affiche un comportement anormal, déconnectez-le du réseau en coupant le Wi-Fi ou en retirant le câble Ethernet. Ne le réinitialisez pas immédiatement et n’effacez pas ses fichiers : ces actions peuvent supprimer des informations utiles au diagnostic. Si un compte en ligne est suspect, utilisez depuis un appareil sain la fonction de déconnexion des sessions, de révocation des accès ou de suspension du compte.

Pour un site web, mettez si possible le site en maintenance ou limitez temporairement les accès d’administration. Pour une boîte mail, vérifiez si une règle de transfert inconnue a été créée, mais évitez de supprimer les éléments avant d’avoir relevé leur contenu et leur date de création.

Révoquer les accès les plus sensibles

Commencez par les comptes qui peuvent entraîner d’autres compromissions : adresse mail principale, gestionnaire de mots de passe, hébergement, nom de domaine, banque, publicité en ligne et outils contenant des données clients. Modifiez les mots de passe depuis un appareil de confiance et activez l’authentification multifacteur lorsque le service le permet.

Un changement de mot de passe ne suffit pas toujours. Les sessions déjà ouvertes, les clés d’API, les applications connectées et les règles de transfert peuvent rester actives. Recherchez donc les appareils connectés, les autorisations accordées et les méthodes de récupération ajoutées récemment.

Éviter la communication improvisée

Ne contactez pas tous vos clients ou abonnés avec un message non vérifié. Une communication précipitée peut diffuser une information fausse ou donner des détails exploitables. Désignez une personne chargée de centraliser les faits et utilisez un canal de discussion différent du compte potentiellement compromis.

Constituer une fiche d’incident exploitable

Une fiche simple permet de séparer les faits, les hypothèses et les décisions. Elle peut être tenue dans un document hors ligne ou dans un espace dont l’accès a été vérifié. L’objectif n’est pas de produire un rapport juridique complet, mais de conserver une chronologie fiable.

Conservez les captures d’écran avec leur date et ne modifiez pas les fichiers de journalisation si vous ne savez pas comment les exporter proprement. Ne tentez pas de « piéger » l’attaquant ni de lancer des recherches agressives : ces actions peuvent aggraver la situation et compliquer l’analyse.

Évaluer le périmètre avant de restaurer

Une restauration rapide peut remettre un service en ligne tout en laissant la porte ouverte. Avant de réinstaller ou de récupérer une sauvegarde, recherchez les traces d’accès anormaux et vérifiez les comptes privilégiés. Pour un site, contrôlez notamment les utilisateurs administrateurs, les extensions, les fichiers récemment modifiés, les tâches planifiées et les clés d’accès utilisées par les services externes.

Pour un compte cloud, examinez les connexions récentes, les téléchargements inhabituels, les appareils autorisés et les règles automatiques. Pour un poste de travail, demandez-vous si d’autres appareils ont utilisé le même mot de passe ou si des fichiers ont été synchronisés vers un service partagé.

Le périmètre doit aussi inclure les prestataires. Un hébergeur, un développeur, un comptable ou un outil d’automatisation peut posséder des accès importants. Vérifiez les autorisations accordées à ces tiers et informez-les si leurs identifiants risquent d’être concernés.

Restaurer l’activité dans un ordre maîtrisé

La reprise ne consiste pas à rallumer tous les services en même temps. Classez-les selon leur importance pour l’activité et leur niveau de risque. Une adresse mail administratrice ou un compte d’hébergement doit être sécurisé avant le site qui en dépend.

1. Sécuriser l’identité principale : compte mail, gestionnaire de mots de passe et moyens de récupération.
2. Révoquer les accès persistants : sessions, applications connectées, clés, utilisateurs inconnus et règles automatiques.
3. Corriger la cause probable : appareil compromis, extension vulnérable, mot de passe exposé ou autorisation excessive.
4. Restaurer depuis une source connue : sauvegarde antérieure à l’incident, vérifiée et conservée séparément.
5. Tester avant de communiquer : connexion, formulaires, paiements, notifications, droits utilisateurs et journaux.
6. Surveiller après la reprise : alertes, connexions, modifications et erreurs pendant une période renforcée.

Une sauvegarde ne doit pas être considérée comme saine uniquement parce qu’elle est disponible. Si elle a été créée après la compromission, elle peut contenir le problème. Lorsque l’incident concerne un site ou un serveur, demandez l’avis de l’hébergeur ou d’un professionnel avant de remettre les données en production.

Informer les bonnes personnes au bon moment

La liste de contacts doit être préparée avant la crise : hébergeur, prestataire informatique, responsable de l’outil concerné, assureur éventuel et personnes décisionnaires. Ajoutez les coordonnées hors du système principal afin de pouvoir les consulter si les comptes sont indisponibles.

La communication externe dépend de la nature de l’incident. Si des données personnelles sont susceptibles d’avoir été exposées, les obligations varient selon le contexte, la nature des données et le rôle de l’organisation. Il faut alors documenter les faits et demander rapidement conseil à la personne compétente ou à l’organisme concerné, plutôt que minimiser l’événement ou promettre qu’aucune donnée n’a été consultée sans preuve.

Un message destiné aux clients doit rester factuel : ce qui est confirmé, les services concernés, les mesures prises et la façon de vous contacter. Ne demandez jamais aux destinataires de transmettre un mot de passe ou un code de sécurité pour « vérifier » leur compte.

Transformer l’incident en plan de prévention

Le retour d’expérience doit intervenir une fois l’urgence passée. Il ne s’agit pas de chercher un responsable, mais d’identifier les conditions qui ont permis l’incident et les contrôles manquants.

• Quels accès étaient trop nombreux ou trop anciens ?
• Les comptes importants disposaient-ils d’une authentification multifacteur ?
• Les sauvegardes étaient-elles accessibles depuis les mêmes comptes que la production ?
• Les journaux et alertes étaient-ils disponibles au moment de l’analyse ?
• La procédure était-elle compréhensible par une personne non technique ?
• Quels fournisseurs doivent être contactés plus rapidement la prochaine fois ?

Actualisez ensuite la liste des comptes, réduisez les privilèges inutiles, vérifiez les sauvegardes et entraînez les personnes concernées avec un scénario simple. Une procédure utile tient sur quelques pages et indique clairement qui fait quoi, depuis quel appareil et dans quel ordre.

Le meilleur moment pour préparer cette procédure est avant le prochain incident. Commencez par inscrire les contacts d’urgence, les services critiques, la méthode de sauvegarde et les étapes de révocation des accès. Cette préparation ne supprimera pas tous les risques, mais elle réduira le temps perdu au moment où chaque décision compte.