Traduction fournie à titre indicatif. La version anglaise fait foi.
Ce plan indique ce que fait LFW lorsqu’un incident de sécurité est soupçonné ou confirmé, sur ses propres systèmes ou sur le site d’un client. Il est court parce que LFW est petite : une personne agit, et voici l’ordre dans lequel elle agit.
Version 1.0, 6 octobre 2026. Fait partie des pratiques publiées sur la page Confiance. Les étapes de réponse pour le site d’un client suivent l’annexe de gestion (en anglais).
1. Ce qui compte comme incident
Un accès non autorisé à un système que LFW exploite ou dans lequel elle travaille ; la compromission du site d’un client ; la perte ou l’exposition de données de clients ou de visiteurs ; un identifiant de LFW qui a pu fuiter ; ou une défaillance du processus de mise en production de LFW qui rend un site indisponible.
Un signalement de vulnérabilité sans signe d’exploitation est traité selon la politique de divulgation des vulnérabilités, pas selon ce plan, sauf s’il montre que des données ont été atteintes.
2. Qui agit, et quand
Leland Fiegel, fondateur de LFW, est responsable de chaque incident. Il n’y a ni roulement d’astreinte ni permanence hors des heures ouvrées : LFW agit pendant les heures ouvrées. Du lundi au vendredi, de 9 h à 17 h, heure de l’Est (de 6 h à 14 h, heure du Pacifique), hors jours fériés fédéraux. Nous n’assurons ni permanence en dehors de ces heures ni astreinte.
En dehors de ces heures, l’hébergeur du client surveille et assiste les serveurs 24 heures sur 24 selon ses propres conditions, et un client peut signaler une compromission dans le Portail client à toute heure. LFW commence la restauration du site compromis d’un client depuis la sauvegarde de l’hébergeur dès le jour ouvré suivant.
3. Notification
Si LFW confirme un incident de sécurité qui touche les données ou le site d’un client, elle en informe ce client dans les 24 heures suivant sa confirmation, par écrit, par courriel aux contacts enregistrés, avec ce qui est connu, ce qui ne l’est pas encore et ce que LFW fait.
Lorsque le contrat d’un client ou la loi fixe un délai plus court ou un contact désigné, c’est celui-ci qui s’applique. LFW respecte les lois applicables en matière de notification des violations de données et appuie la notification que le client adresse lui-même aux personnes concernées.
Un chercheur en sécurité qui signale un problème selon la politique de divulgation reçoit une réponse sous deux jours ouvrés, puis apprend le plan et la date de mise en ligne du correctif.
4. Étapes pour les systèmes propres de LFW
Contenir. Révoquer les sessions ou les jetons concernés ; changer tout secret qui a pu être exposé ; si nécessaire, bloquer le trafic chez Cloudflare ou arrêter le service.
Préserver. Conserver les journaux du serveur web et les enregistrements de l’application pour la période. Prendre un instantané de sauvegarde avant de modifier quoi que ce soit, pour que l’état au moment de la découverte soit conservé.
Restaurer. Revenir à la version précédente, conservée sur le serveur, ou restaurer les données depuis l’instantané sain le plus récent. Les sauvegardes ont lieu chaque jour et à chaque mise en production, avec une copie hors site.
Corriger et vérifier. Livrer le correctif par la mise en production habituelle et ses contrôles, puis le confirmer sur le site en ligne avec les vérifications de LFW Monitor et à la main.
5. Étapes pour le site d’un client
Contenir. Durcir les règles de pare-feu chez Cloudflare et dans Wordfence, réinitialiser avec le client les sessions et les identifiants administrateur du site, et passer le site en mode maintenance s’il nuit activement aux visiteurs.
Restaurer. Restaurer depuis la sauvegarde saine la plus récente de l’hébergeur, en commençant dès le jour ouvré suivant, comme le prévoit le contrat de gestion. L’offre de l’hébergeur détermine jusqu’où remonte une sauvegarde.
Enquêter. Lire le journal d’activité et les journaux d’accès de l’hébergeur pour établir comment et quand le site a été atteint. Une analyse forensique plus poussée et un nettoyage au-delà de la restauration constituent un projet, chiffré par écrit avant le début du travail, comme le prévoit l’annexe.
Fermer la brèche. Mettre à jour ou retirer le composant utilisé, confirmer la règle de pare-feu qui le couvre et revérifier le site avec LFW Monitor.
6. Le compte rendu écrit
Chaque incident fait l’objet d’un compte rendu écrit privé : ce qui s’est passé, quand cela a été découvert, ce qui a été fait et quand, quelles données étaient concernées et ce qui a changé ensuite pour que cela ne se reproduise pas. Le client reçoit ce compte rendu pour un incident sur son site ou touchant ses données.
Les entrées du journal des modifications public décrivent le correctif, jamais les détails de l’incident. Lorsqu’un incident modifie une pratique de la page Confiance, la version et la date de la politique changent.
7. Tester ce plan
Le processus de mise en production est testé à chaque déploiement : une nouvelle version répond à ses vérifications de routes avant que le trafic bascule, et la version précédente reste disponible. Les sauvegardes sont vérifiées au moment où elles sont prises, et le dépôt de sauvegarde est vérifié chaque semaine.
LFW n’a pas encore mené d’exercice de restauration planifié sur une copie de ses données de production, et le dit ici au lieu de revendiquer un test annuel.
Pour signaler un incident : les clients, dans le Portail client ou à hello@lfw.com ; toute autre personne, à security@lfw.com.