Incident CrowdStrike

Ci-après, retour sur l’Incident de l’été.

Difficile de le résumer en quelques mots et l’objectif n’est surtout pas d’incriminer tel ou tel Éditeur, mais plutôt d’en comprendre le cheminement et d’en tirer chacun un enseignement.

Résumé de l’incident :

Le vendredi 19 juillet, l’éditeur de produit d’EDR (entre autres) Crowdstrike, a envoyé une mise à jour de contenu à tous les agents Windows. Ceci à l’échelle mondiale.

Le contenu était l’ajout de nouvelles règles de détection de menaces.

En soit, ce type de mise à jour de contenu est très fréquent.

Malheureusement le nouveau contenu était déficient, il a immédiatement causé le crash de Windows sur lequel l’agent était installé puisque comme n’importe quel produit EDR, il est déclaré comme logiciel essentiel.

Conséquence, s’il plante, il emporte l’intégralité de l’OS avec lui et Windows refuse de démarrer normalement si ce logiciel n’est pas en cours d’exécution.

Autrement dit toutes les machines Windows protégées par Crowdstrike ne pouvaient plus être utilisées.

Seul moyen fiable de récupérer la main sur la machine, se connecter physiquement en local, en mode « sans échec », puis supprimer le contenu rajouté par cette mise à jour.

Au regard de votre parc vs votre staff, vous pouvez ainsi imaginer le temps nécessaire à la réalisation de ces tâches manuelles.

Et comme malus vous rajoutez la période estivale pour notre hémisphère, du multisite, et éventuellement des process de sécurité d’accès.

« Leader du marché » :

Crowdstrike fait partie des leaders mondiaux.

Le Gartner ou le Forrester, par exemple, positionnent très bien l’Editeur dans la catégorie Endpoint.

Et c’est là qu’une première leçon peut être tirée.

Même si la notion de part de Marché et de pertinence technique restent des bons indicateurs de fiabilité, il faut nuancer avec la capacité qu’à l’Éditeur à assurer « le service après-vente », en fonction de ses ressources, de sa propre expérience et de ses choix de priorités.

Problème de qualité :

Les erreurs sont humaines et aucun système (ni Éditeur) n’est infaillible.

Raison de plus pour disposer d’un contrôle qualité adapté. Encore plus en Cyber.

Ceci est à mettre au conditionnel mais ici ce qui est reproché à l’Éditeur américain, ce n’est pas une, mais deux erreurs majeures :

·         Le contenu des mises à jour n’était pas testé suffisamment :

o   L’usage d’outils de vérifications automatique est souvent utilisé, dans ce cas, il semblerait que les configurations de ces outils n’étaient pas complètes.

o   L’usage de serveurs de tests qui permettent de tester si le logiciel fonctionne correctement suite aux mises à jour… ce n’était pas le cas ici.

o   L’usage d’un déploiement progressif qui permet d’identifier le problème suffisamment tôt avant que la mise à jour soit déployée complètement.

Crowdstrike a admis ne pas fonctionner ainsi.

·         Le process qui lit ce contenu n’était pas en capacité de gérer si le contenu était invalide :

o   L’usage de revue par les pairs est aussi généralisé, le concept est qu’un développeur plus expérimenté relis le code effectué par d’autres développeurs avant qu’il ne soit validé.

Pas d’éléments à ce sujet, donc difficile à dire si le processus n’a pas été mis en place ou si la revue a été mal faite.

o   L’usage de test unitaire est très courant. L’idée est de tester que chaque partie du code fonctionne comme attendue.

CrowdStrike admet dans son rapport que deux parties de code censées prévenir de ce type de problématique n’ont pas été testées.

Ces pratiques sont le standard chez de nombreux Éditeurs, quel que soit leur taille.

Les leçons :

Ces dernières années ont montré que ça n’arrive pas qu’aux autres. Ainsi plusieurs pistes peuvent être suivies :

·         Prévoir des postes et serveurs non protégés par des agents. Ces derniers doivent être isolés (voire éteint).

·         Eviter un parc serveur avec un OS largement majoritaire, Windows ou sur une même distribution Linux.

·         Pour les plus grandes entités, éviter un parc utilisateur avec un OS largement majoritaire.

L’un de nos clients a fait le choix d’intégrer des Chromebook en parallèle des postes Windows, par exemple.

·         Effectuer et tester régulièrement les sauvegardes des serveurs.

·         Disposer de Plan de Reprise d’Activité complet.

Des responsabilités partagées :

L’objectif n’est pas de simplement regarder la partie Crowdstrike, bien qu’ils soient ici responsables d’une grande partie de l’incident.

Il ne faut pas oublier que l’ampleur de ce dernier a aussi été permis par d’autres acteurs :

·         Microsoft

Pour de multiples raisons, Windows ne permet pas de récupérer toutes les informations requises par les logiciels EDR sans qu’ils ne se mettent en logiciel essentiel (comprendre logiciel qui s’exécute à la couche noyau de l’OS au même titre qu’un pilote matériel, au lieu de la couche utilisateur). Si cela était possible (comme ce qui est proposé sur MacOS par exemple) cet incident n’aurait jamais pu causer ce niveau de paralysie.

·         Certains clients

Certaines organisations majeures ont particulièrement été impactés, d’une part, lié à un manque de diversité d’usage de l’OS en interne, d’autre part, causé par une absence de PRA adapté.