Le 19 juillet 2024 restera dans les annales : une mise à jour de canal de CrowdStrike Falcon a provoqué le BSOD de 8,5 millions de machines Windows à travers le monde. Aéroports, hôpitaux, médias — l'impact a été massif. Un an plus tard, voici ce que cet incident a changé pour notre Security Operations Center.
Pas de « confiance aveugle » dans les agents
Même les solutions de sécurité les plus matures peuvent provoquer une indisponibilité majeure. Nous avons formalisé une politique de déploiement progressif : aucun agent EDR n'est désormais déployé en bulk sur 100 % d'un parc client sans phase canary préalable.
Intégration de la « Sensor Update Policy » CrowdStrike
Désormais, nos clients peuvent piloter finement la fréquence et le canal de mise à jour de leurs capteurs Falcon : N-1, N-2, ou contrôle manuel. Le cas d'usage : repousser les rapid response content updates de 24h sur les machines critiques.
Plan de continuité Falcon-down
Nos playbooks intègrent désormais un scénario « EDR principal indisponible ». La supervision NDR prend le relais sur le périmètre concerné, avec une corrélation manuelle pendant la période d'indisponibilité.
Audit fournisseur renforcé
Côté contractuel, nous demandons à nos clients d'inclure dans leurs négociations avec les éditeurs de sécurité des clauses sur la politique de tests pré-production et de déploiement progressif.
L'incident Falcon a paradoxalement renforcé l'écosystème : CrowdStrike a publié un post-mortem détaillé et durci ses procédures internes. La leçon dépasse largement le cas CrowdStrike — c'est l'ensemble de notre dépendance aux endpoints en mode kernel qui mérite réflexion.
L'équipe SOC