Plan de réponse aux incidents de sécurité d’un site web

Un plan de réponse aux incidents n’est pas un document rédigé après une attaque. C’est une manière répétée de prendre des décisions lorsqu’une règle WAF bloque le paiement, qu’un jeton API est exposé, qu’une campagne de bots surcharge une origine ou qu’un événement de sécurité peut impliquer des données clients.

Le plan doit servir les personnes techniques comme non techniques. Les ingénieurs ont besoin de l’autorité et des accès nécessaires pour contenir un événement. Les équipes opérations et relation client ont besoin de faits vérifiés, pas de suppositions. La direction et les équipes juridiques doivent comprendre l’impact, les obligations et les décisions. Le meilleur moment pour convenir de ces rôles est avant un incident.

Définissez ce qui constitue un incident

Chaque requête en échec n’est pas un incident de sécurité. Définissez des catégories et exemples afin que les équipes ne perdent pas de temps à débattre de la gravité pendant une interruption. Une taxonomie pratique de la sécurité web comprend le credential stuffing présumé, le DDoS ou l’épuisement des ressources, le contournement de l’origine, les faux positifs WAF, les identifiants ou clés compromis, les comportements API malveillants, l’exposition de scripts tiers et une suspicion de divulgation de données.

Définissez la gravité selon l’impact métier et le niveau de confiance, pas uniquement le volume de trafic. Considérez les parcours clients affectés, les données sensibles, le périmètre géographique, la durée, les dépendances de service et le fait qu’un contrôle soit contourné. Un petit événement sur la réinitialisation de mot de passe ou la confirmation de paiement peut être plus urgent qu’un scan bruyant contre une page publique.

Attribuez les rôles et l’autorité de décision

Chaque plan nécessite des rôles nommés et des remplaçants. Dans une petite équipe, une même personne peut couvrir plusieurs rôles, mais leurs responsabilités doivent rester distinctes :

• Responsable de l’incident : est propriétaire de la gravité, des priorités, du journal des décisions et de la fin de l’incident.
• Responsable technique : dirige l’investigation, le confinement et la reprise entre les équipes de périphérie, application et infrastructure.
• Responsable communication : prépare les mises à jour internes et les déclarations destinées aux clients à partir de faits vérifiés.
• Contact juridique et confidentialité : évalue les obligations de notification, contractuelles et réglementaires.
• Relais fournisseur : ouvre et gère les escalades auprès des fournisseurs de CDN, WAF, hébergement, DNS, paiement ou identité.

Conservez les contacts d’urgence, identifiants de compte, droits de support et canaux d’escalade dans un emplacement contrôlé par les accès mais accessible. Rendez l’accès break-glass limité dans le temps, authentifié séparément, entièrement journalisé et revu après utilisation.

Préparez des preuves qui relient le chemin de livraison

Les incidents web traversent les couches. Les journaux de périphérie peuvent montrer un challenge ou un blocage ; les journaux applicatifs peuvent indiquer un échec d’autorisation ; la télémétrie d’origine peut révéler une dépendance lente. Préservez un ensemble de preuves minimal qui permet de les relier :

• Horodatages coordonnés et source de temps utilisée par chaque système.
• ID de requête, de trace ou de corrélation de la périphérie jusqu’à l’origine.
• Décisions WAF, bots, limites de débit, CDN, DNS, application et authentification pertinentes.
• Versions de déploiement et de configuration, y compris les changements de cache et de pare-feu.
• Hôtes, routes, parcours clients, régions et fenêtres temporelles affectés.
• Signaux métier tels que les connexions, paiements, finalisations API et contacts au support.

Ne copiez pas de secrets, corps de requête non expurgés, données de paiement ou jetons de session dans une discussion d’incident. Appliquez la conservation des journaux, les contrôles d’accès et la politique de confidentialité aux preuves d’urgence comme vous le feriez en fonctionnement normal.

Triez, contenez et rétablissez par étapes

1. Stabilisez le service

Confirmez l’alerte avec des signaux indépendants. Vérifiez les parcours synthétiques, les signaux d’utilisateurs réels, les journaux de décision de périphérie, la santé de l’origine et les mises en production récentes. Commencez un dossier d’incident avec les faits actuels, les hypothèses, le responsable et l’heure de la prochaine mise à jour.

2. Délimitez l’événement

Identifiez ce qui est affecté et ce qui ne l’est pas : site public, API, connexion, administration, une région, un fournisseur ou un chemin d’origine. Distinguez un blocage de périphérie d’une défaillance d’origine, un signalement client d’un abus vérifié et un pic de trafic d’une compromission confirmée.

3. Appliquez le confinement efficace le plus étroit

Utilisez une règle WAF ciblée, une limite de débit, la désactivation d’une route, la révocation d’identifiants, une modification du pare-feu d’origine ou un basculement de trafic répondant au comportement connu. Consignez le changement de configuration exact et l’étape de retour en arrière. Évitez les blocages larges par pays, IP ou user-agent, sauf si les preuves et l’impact métier les justifient.

4. Éradiquez la cause et validez la reprise

Faites tourner les identifiants affectés, supprimez le chemin vulnérable, déployez un correctif, corrigez une politique ou restaurez une configuration connue comme saine. Validez le parcours utilisateur, le comportement API, le contrôle de sécurité et la supervision depuis plusieurs emplacements. Ne déclarez pas la reprise parce que le volume d’alertes a baissé ; confirmez que la condition nuisible initiale a disparu et que les utilisateurs légitimes peuvent effectuer les tâches critiques.

Communiquez les faits, l’impact et les prochaines mises à jour

Définissez une fréquence régulière de mises à jour. Les mises à jour internes doivent indiquer le responsable de l’incident, l’impact confirmé, les actions entreprises, le risque actuel et le prochain point de décision. Les communications destinées aux clients doivent préciser ce qui est connu, quel service est affecté, ce que les clients doivent faire le cas échéant et quand la prochaine mise à jour arrivera. Distinguez les faits confirmés des hypothèses actives.

Les escalades auprès des fournisseurs sont plus efficaces avec une demande courte et structurée : ID de compte ou de service, heure de début et fuseau horaire, nom d’hôte ou endpoint affecté, ID de requête, région, réponse observée, profil de trafic, changements déjà effectués et impact métier. N’envoyez pas d’identifiants ni de charges sensibles via un canal de support non approuvé.

Tirez les leçons et entraînez-vous

Après la reprise, organisez une revue sans blâme tant que la chronologie est fraîche. Expliquez ce qui s’est passé, pourquoi les contrôles ont fonctionné ou non, quelles décisions ont été difficiles et ce qui doit changer. Chaque amélioration nécessite un responsable et une date d’échéance : tableau de bord manquant, exception WAF plus étroite, lacune d’authentification de l’origine, mise à jour du runbook ou meilleure alerte client.

Entraînez le plan avec des exercices sur table et des tests contrôlés. Utilisez des scénarios réalistes : un DDoS contre la connexion, une clé API divulguée, une IP d’origine exposée via un ancien DNS, une panne fournisseur, un pic malveillant de webhooks et un changement WAF qui bloque le paiement. Un plan qui n’a pas été exercé reste une hypothèse.

Liste de contrôle du plan d’incident

Avant un incident, vérifiez que les rôles et contacts sont à jour ; que les journaux de périphérie et d’origine partagent un chemin de corrélation ; que l’accès d’urgence est testé ; que les fournisseurs critiques disposent d’une voie d’escalade ; que les communications clients sont rédigées ; que des procédures de retour en arrière existent ; et que l’équipe a répété au moins un scénario technique et un scénario transverse.

Pour les contrôles qui contribuent à réduire la surface d’incident, lisez Protection DDoS, Configuration WAF et Comment protéger votre serveur d’origine.

Références faisant autorité

• NIST SP 800-61 Rev. 3: Incident Response Recommendations
• CISA: Incident Response Plan Basics
• OWASP Logging Cheat Sheet
• Cloudflare Logpush documentation