Panne Crowdstrike : premiers enseignements pour les DSI et RSSI

Que vous ayez survécu à la panne géante Crowdstrike ou que vous n'utilisiez pas cette solution et que vous ne fassiez que constater l'impact sur les autres, il est vital de prendre le temps de tirer les leçons de cet événement. Après tout, si vous n'avez pas pu vous en remettre facilement, vous risquez bien d'être perdu quand vous ferez face à une attaque par ransomware. Les enseignements à tirer amènent à des changements potentiels que vous pourriez envisager d'apporter à vos stratégies de recrutement, à vos processus techniques, à vos canaux de communication et à votre culture d'organisation. Mais aussi à votre approche de la sécurisation de vos actifs en général. La liste des enseignements tirés de l'affaire Crowdstrike s'allongera probablement au fur et à mesure que de nouvelles informations seront révélées sur l'impact de la panne sur les organismes du monde entier. Mais pour l'instant, reconsidérer ou renforcer votre stratégie concernant les processus et les ressources clés afin de garantir une réponse plus robuste à l'avenir doit être envisagé.

Revoir l'organisation de vos ressources RH

Rétablir les systèmes en conditions opérationnelles suite à l'attaque de Crowdstrike a été un processus compliqué auquel de nombreuses personnes ont participé. Dans certains cas, les entreprises ont dû faire appel à des humains pour redémarrer les machines touchées afin de les remettre en état, un processus ardu, en particulier à grande échelle. Si vous avez confié vos opérations informatiques à des fournisseurs de services managés, sachez que ces derniers n'ont peut-être pas assez de personnel pour résoudre vos problèmes en même temps que ceux de leurs autres clients, en particulier lorsqu'un événement unique a des répercussions à grande échelle. Au lieu de cela, il se peut que vous ne puissiez faire appel qu'à votre personnel existant pour remédier à la situation et pour former des personnes peu habituées aux tâches technologiques à effectuer des étapes clés afin d'aider à rétablir votre réseau en ligne le plus rapidement possible. Par ailleurs, vous devrez peut-être envisager d'expédier du matériel de remplacement ou d'autres moyens de réinstaller ou de rafraîchir les systèmes d'exploitation, comme ce fut le cas avec Crowdstrike : autant d'opérations qui nécessitent du personnel. Or les équipes réduites qui dépendent trop des fournisseurs de services risquent de ne pas pouvoir reprendre le travail après un incident, quelle qu'en soit la source.

Renforcer les moyens techniques

Remettre en marche un environnement plus sûr est une bonne chose, mais votre prochain obstacle pourrait être l'accès à un élément destiné à protéger votre système : Bitlocker. Lorsque l'ordinateur redémarre après être passé en mode sans échec, si Bitlocker est activé, il vous sera en effet demandé d'entrer une clé de récupération. Par expérience, le plus souvent, l'accès à ses clés peut prendre du temps : elles peuvent être sauvegardées dans son Active Directory local, imprimées et sauvegardées à un endroit qui, dans le feu de l'action, risque d'être oublié. Veillez ainsi à revoir régulièrement les étapes et les processus de récupération afin de garantir que votre équipe sait exactement où se trouvent ces clés et quels sont les processus nécessaires pour les obtenir. Bien que Bitlocker soit souvent imposé pour des raisons de conformité, il ajoute également une couche de complications à laquelle vous n'êtes peut-être pas préparé. Au cours de cet événement, nous avons vu des solutions de contournement intéressantes pour rendre les systèmes opérationnels. Sur les réseaux sociaux, des personnes comme LetheForgot ont partagé ce qui suit : « Nous sommes allés dans les options de redémarrage avancées pour lancer l'invite de commande, ignorer la demande de clé bitlocker qui nous a ensuite amenés au lecteur X et lancé 'bcdedit /set {default} safeboot minimal' qui nous a permis de démarrer en mode sans échec et de supprimer le fichier sys à l'origine du bsod. » Une autre personne a recommandé : « Même en mode sans échec, l'accès au dossier Crowdstrike était refusé. J'ai utilisé cacls pour donner plus de droits à l'utilisateur (en contournant l'administrateur) et j'ai supprimé le fichier. »

Si vous vous demandez pourquoi cela fonctionne et ne demande pas de clé de récupération Bitlocker, sachez que lorsque l'ordinateur démarre en mode sans échec par défaut, ce n'est pas quelque chose qui devrait être chiffré. Vous devez toujours fournir des informations d'identification valides pour accéder au lecteur C, ce qui soulève le prochain obstacle à la récupération de l'accès. Avez-vous accès au contrôleur de domaine ou devrez-vous accéder à un nom d'utilisateur local pour accéder au lecteur C et supprimer le fichier que vous devez supprimer pour restaurer une machine fonctionnelle ? Si vous avez utilisé LAPS ou un logiciel qui randomise le mot de passe de l'administrateur local, vous devrez également avoir accès à cette ressource. Une fois que vous avez accès à la machine, vous pouvez supprimer le fichier à l'aide de la commande suivante : del C-00000291*.sys. La leçon à en tirer n'est pas seulement de revoir souvent les étapes de récupération, mais aussi de suivre de près les discussions de la communauté pour trouver des solutions techniques créatives en cas de catastrophe informatique collective.

Construire une culture de la communication

Cet incident met en évidence aussi une autre ressource clé nécessaire lors dans ce genre de situation : des informations claires sur ce qui se passe et sur ce qu'il faut faire. Tard dans la soirée du jeudi 18 juillet, les commentaires sur les médias sociaux ont clairement montré qu'il se passait quelque chose. Le coupable a également été rapidement identifié : une mise à jour de Crowdstrike qui s'est avérée défectueuse. Dans d'autres situations d'incident, il se peut que vous ne soyez pas informé aussi rapidement. Il se peut que vous ne sachiez pas clairement ce qui s'est passé et quels actifs ont été touchés. Souvent, vous devrez contacter le personnel qui travaille en étroite collaboration avec les actifs touchés pour déterminer ce qui se passe et les mesures à prendre. Souvent, ce que vous pensez être le problème et les mesures à prendre ne sont pas nécessairement les mesures que vous devez prendre. Il se peut aussi que vous trouviez des mesures plus simples à prendre. En outre, il peut être nécessaire de déterminer si un plan B peut être plus bénéfique en tant que plan d'action. Dans ce cas, il n'est pas rare de voir des entreprises décider d'avancer les plans de redéploiement des systèmes informatiques pour remplacer les machines touchées. Étant donné qu'un rafraîchissement du matériel était prévu dans les semaines à venir, elles ont simplement avancé les plans de redéploiement du matériel plutôt que d'essayer de réparer les machines. Tout cela nécessite une communication claire entre toutes les parties concernées : une culture que l'on doit développer, en plus de mettre en place des stratégies et des processus de communication en cas d'incident.

Réévaluer les stratégies à la lumière des enseignements tirés

Comme pour tout incident, le nettoyage et le suivi sont essentiels. Pour ceux dont les terminaux ont été sauvegardés et récupérés après l'attaque de Crowdstrike, il y a certains points à revoir. Tout d'abord, il faut envisager de rééditer les clés de récupération Bitlocker. Si vous avez distribué la clé de récupération manuellement, envisagez de rééditer les clés et de les faire tourner. Si vous envisagez de modifier votre infrastructure, plutôt que d'abandonner votre technologie et de la remplacer par un système d'exploitation différent, envisagez de modifier la manière dont vous déployez les logiciels et de restreindre les logiciels autorisés à fonctionner sur ces machines à usage spécifique. Nous utilisons des antivirus parce que nous n'avons pas de limite à ce que nous autorisons sur nos systèmes. Si nous consacrions du temps et des ressources à limiter ce qui est autorisé à fonctionner, les machines seraient plus sûres. Bien entendu, il convient de reconsidérer le système d'exploitation utilisé et l'usage qui en est fait. Nous avons vu trop de messages sur les médias sociaux montrant des écrans bleus et cela soulève quelques questions : avez-vous vraiment besoin d'un système d'exploitation complet pour simplement fournir des informations ? Existe-t-il d'autres moyens de fournir ces mêmes informations ? Ne devriez-vous pas compter sur les fournisseurs pour effectuer leur propre contrôle qualité ?

Qu'il s'agisse de Microsoft ou de Crowdstrike, il n'est pas certain que la diminution des budgets alloués aux personnes chargées des tests soit la véritable cause des problèmes. Dans le cas de Crowdstrike, c'est une erreur logique dans la mise à jour du capteur de l'agent Falcon qui est en cause. La manière dont cette erreur s'est produite devra être éclaircie au cours des retombées. Même si vous n'avez pas été touché par cet événement, vous devriez peut-être revoir la vitesse à laquelle vous déployez les fichiers de mise à jour. Qu'il s'agisse des mises à jour des fournisseurs ou des définitions, vous pouvez considérer que nous faisons trop confiance à la diligence de nos fournisseurs. Or étant donné que de nombreuses entreprises réduisent leurs budgets, on ne peut plus considérer ce contrôle de qualité comme acquis. Envisagez donc d'avoir des circuits de mise à jour spécifiques et de mettre en place vos propres processus de test et de validation lorsqu'il s'agit de déployer des mises à jour, même pour les antivirus et les suites de sécurité. En fin de compte, dites vous qu'aucun logiciel ne devrait être totalement fiable.