Et si la cyber-résilience était la principale leçon de l’incident Crowdstrike ?

Le déroulé des évènements : l’EDR, l’acteur clé

L’incident informatique est lié à une mise jour logiciel d’un composant EDR (Endpoint Detection & Response). La solution mise en cause est une solution en mode SaaS qui, régulièrement fait des mises à jour sur les postes de travail et serveurs afin de protéger ceux-ci contre des attaques cyber. Cette mise à jour a été délivrée avec un bug qui a eu pour conséquence de créer une « error logic ». Elle-même a provoqué un crash sur les postes de travail et serveurs ayant l’agent EDR Crowdstrike.

L'EDR est un logiciel de sécurité qui est capable d’identifier un processus anormal dans des environnements Windows, Linux, etc. A la différence de l’antivirus qui dispose juste d’une bibliothèque de signature de virus, malware, l’EDR surveille en temps réel l’activité d’un utilisateur et de son environnement pour identifier des anomalies, l’installation de codes malveillants, la modification de fichiers propres à OS (Windows par exemple). Il peut initier des actions de remédiations pour bloquer le poste de travail, éliminer un malware, etc. Mais pour cela, l’EDR a besoin de disposer de droits et de privilèges pour opérer. C’est bien ce point qui doit nous faire réfléchir.

Replacer l’incident dans le contexte de l’intégration

Crowdstrike n’est pas le premier éditeur à avoir subi ce type de revers, il faut se rappeler ses concurrents qui, dans les années précédentes, ont eu à gérer des incidents qui n’étaient pas que des problèmes de mises à jour. Le problème de Crowdstrike doit être vu comme une vulnérabilité si on considère que la mise à disposition d’une mise à jour est une fragilité dans son processus métier non testé ou validé.

Cet incident s’inscrit aussi dans un contexte global d’intégration avec d’autres acteurs comme Microsoft et dans un environnement cloud puisque le service affecté est fourni en mode SaaS. C’est bien ce contexte qu’il faut mettre en perspective.

Vous avez un composant logiciel EDR qui dispose des privilèges sur Windows pour opérer ses tâches. Mais pour qu’il puisse réaliser ses tâches avec efficacité, il a besoin de se connecter à son propre cloud afin d’opérer d’autres tâches qui sont mutualisées pour l’ensemble des clients dans une perspective de gain économique. Dans notre cas, il s’agit d’un composant qui a presque tous les droits sur l’environnement OS du client.

Dès lors que cette mise à jour a affecté l’environnement Office 365 et les serveurs, elle a eu pour conséquence d’interrompre l’activité d’un grand nombre de Serveurs/Ordinateurs connectés à Office 365 et les serveurs. Certaines entreprises ont pu réagir car elles disposent d’équipes, de point de restauration (back-up) et d’équipes IT mobilisables. D’autres n’ont pas ces moyens et elles doivent faire face à des enjeux de ressources, de compétences et n’ont pas forcément de politique de back-up. Enfin, un grand nombre d’entre elles ont des environnements en datacenter, et doivent se déplacer sur site pour effectuer des manipulations parce qu’elles n’ont pas des intégrateurs ou d’infogérances pour les assister.

Il y aura probablement des conséquences logistiques (un avion raté, une opération chirurgicale décalée, un centre de logistique à l’arrêt, des camions qui partent à vide, un commerçant affecté par ce bug), et économiques fortes. Parametrix, par la voix de son CEO Jonatan Hatzor, estime d’ailleurs que les pertes financières pourraient s’élever à environ 15 milliards de dollars au niveau mondial. Mais il y a également déjà des répercussions sur des menaces cyber.

En moins d’une journée un nombre important de nom de domaines avec l’intitulé « Crowdstrike » ont été créés afin de d’abuser de potentiels victimes de ce bug pour vendre et offrir des services de maintenance/services sur les produits Crowdstrike.

L’importance de la cyber-résilience et de penser le partage d’informations

Tout cela se retrouve autour du mot cyber-résilience, un monde ou l’IT et la Cyber joignent pour faire face à un incident.

Imaginons maintenant que le bug de l’EDR soit un implant malveillant. L’attaquant pourra faire ce qu’il veut sans que personne ne le détecte. C’est toute la limite des produits de sécurité : ils sont aussi vecteurs d’attaques (supply chain attack). Comme nous avons pu le voir au travers des médias, quand l’EDR est déployée dans les plus grands comptes on peut imaginer les conséquences possibles et à venir.

Enfin, l’intérêt d’un EDR, lorsqu’il déployé largement est dans le monde, est de collecter énormément de télémétrie lui permettant de découvrir des implants malveillants ou des techniques d’attaquants. Cette télémétrie a donc de la valeur, mais le partage est uniquement pour ses clients et quelques fois à l’insu des clients. 

En soi, le NIS2 a tout son sens car il trace une direction pour que les acteurs de la cyber partagent et communiquent mieux sur la menace. Si nous tirons la leçon de ce bug dans une mise à jour (et peu importe le nom l’éditeur), il faut retenir qu’il est essentiel :

1. D’avoir une bonne communication afin de ne pas laisser l’information être appropriée par d’autres
2. De réagir rapidement (mais pour cela il faut un plan de réponse à incident)
3. D’avoir mis en place ou réfléchi à des mesures préventives (back-up)
4. De faire des tests de restauration 
5. De disposer de ressources techniques (certains clients sont encore dans la difficulté)

Last but not least : un outil de patch management (roll-back) pour maîtriser et contrôler ce que chacun d’entre nous souhaite mettre à jour dans son système d’information.