CrowdStrike a réagi à l'incident récent au cours duquel une mise à jour défectueuse a perturbé 8,5 millions de machines Windows. L'analyse de l'entreprise après l'incident attribue le problème à un bogue dans son logiciel de test, qui n'a pas réussi à valider correctement une mise à jour de contenu diffusée le vendredi 19 juillet dernier. En promettant d'améliorer les protocoles de test et d'échelonner les déploiements, CrowdStrike entend prévenir des perturbations similaires à l'avenir.Le 19 juillet 2024, une panne informatique chez Microsoft a touché des entreprises, des aéroports et des médias à travers le monde entier. Microsoft a confirmé qu'elle était consciente de ces problèmes, mais de nombreux experts en cybersécurité ont indiqué que la source potentielle du problème était l'entreprise de cybersécurité CrowdStrike, qui fournit une surveillance et une protection contre les cyberattaques à de nombreuses entreprises de premier plan. Les écrans bleus de la mort ont perturbé le fonctionnement normal de millions de machines Windows, affichant le message : “Recovery: It looks like Windows didn’t load correctly.”
CrowdStrike a publié une analyse post incident (PIR) de la mise à jour boguée qu'elle a publiée et qui a entraîné la mise hors service de 8,5 millions de machines Windows la semaine dernière. Le rapport détaillé accuse un bogue dans le logiciel de test qui n'a pas validé correctement la mise à jour de contenu qui a été envoyée à des millions d'ordinateurs vendredi. CrowdStrike promet de tester plus minutieusement ses mises à jour de contenu, d'améliorer sa gestion des erreurs et de mettre en œuvre un déploiement échelonné afin d'éviter que ce désastre ne se reproduise.
L'Analyse préliminaire après incident (PIR) de CrowdStrike est présentée ci-dessous :
[QUOTE]
Ceci est l'analyse préliminaire après incident (PIR) de CrowdStrike. Nous détaillerons notre enquête complète dans l'analyse des causes fondamentales qui sera rendue publique. Tout au long de ce PIR, nous avons utilisé une terminologie généralisée pour décrire la plateforme Falcon afin d'améliorer la lisibilité. La terminologie utilisée dans d'autres documents peut être plus spécifique et technique.
Que s'est-il passé ?
Le vendredi 19 juillet 2024 à 04:09 UTC, dans le cadre des opérations régulières, CrowdStrike a publié une mise à jour de la configuration du contenu pour le capteur Windows afin de recueillir des données télémétriques sur d'éventuelles nouvelles techniques de menace.
Ces mises à jour font partie intégrante des mécanismes de protection dynamique de la plateforme Falcon. La mise à jour problématique de la configuration de Rapid Response Content a entraîné un crash du système Windows.
Les systèmes concernés sont les hôtes Windows utilisant la version 7.11 et supérieure du capteur qui étaient en ligne entre le vendredi 19 juillet 2024 04:09 UTC et le vendredi 19 juillet 2024 05:27 UTC et qui ont reçu la mise à jour. Les hôtes Mac et Linux n'ont pas été touchés.
Le défaut dans la mise à jour du contenu a été annulé le vendredi 19 juillet 2024 à 05:27 UTC. Les systèmes mis en ligne après cette heure, ou qui ne se sont pas connectés pendant la fenêtre, n'ont pas été affectés.
Qu'est-ce qui n'a pas fonctionné et pourquoi ?
CrowdStrike fournit des mises à jour de configuration du contenu de sécurité à ses capteurs de deux manières : Sensor Content qui est livré directement avec nos capteurs, et Rapid Response Content qui est conçu pour répondre à l'évolution du paysage des menaces à la vitesse opérationnelle.
Le problème survenu vendredi concernait une mise à jour Rapid Response Content avec une erreur non détectée.
Sensor Content
Sensor Content fournit un large éventail de capacités pour aider à la réponse de l'adversaire. Il fait toujours partie de la publication d'un capteur et n'est pas mis à jour de manière dynamique à partir du cloud. Sensor Content comprend des modèles d'IA et d'apprentissage automatique sur le capteur, et comprend du code écrit expressément pour fournir des capacités réutilisables à plus long terme pour les ingénieurs de CrowdStrike chargés de la détection des menaces.
Ces capacités comprennent des Template Types (types de modèle), qui comportent des champs prédéfinis que les ingénieurs de détection des menaces peuvent exploiter dans le Rapid Response Content Les Template Types sont exprimés en code. Tous les Sensor Content, y compris les Template Types, sont soumis à un processus d'assurance qualité approfondi, qui comprend des tests automatisés, des tests manuels, des étapes de validation et de déploiement.
Le processus de mise à disposition des capteurs commence par des tests automatisés, avant et après l'intégration dans notre base de code. Cela comprend des tests unitaires, des tests d'intégration, des tests de performance et des tests de stress. Cela aboutit à un processus de déploiement du capteur par étapes, qui commence par un test interne chez CrowdStrike, suivi par les utilisateurs précoces. Le capteur est ensuite mis à la disposition des clients. Les clients ont alors la possibilité de sélectionner les parties de leur flotte qui doivent installer la dernière version du capteur (« N »), ou une version plus ancienne (« N-1 ») ou deux versions plus anciennes (« N-2 ») par le biais des politiques de mise à jour des capteurs.
L'événement du vendredi 19 juillet 2024 n'a pas été déclenché par Sensor Content, qui n'est livré qu'avec la sortie d'une mise à jour du capteur Falcon. Les clients ont un contrôle total sur le déploiement du capteur - qui comprend le Sensor Content et les Template Types.
Rapid Response Content
Rapid Response Content est utilisé pour effectuer une variété d'opérations de mise en correspondance de modèles comportementaux sur le capteur à l'aide d'un moteur hautement optimisé. Le Rapid Response Content est une représentation des champs et des valeurs, avec le filtrage associé. Ce Rapid Response Content est stocké dans un fichier binaire propriétaire qui contient des données de configuration. Il ne s'agit pas d'un code ou d'un pilote de noyau.
Le Rapid Response Content est fourni sous la forme de Template Instances (instances de modèles), qui sont des instanciations d'un Template Type donné. Chaque Template Instance correspond à des comportements spécifiques que le capteur doit observer, détecter ou prévenir. Les Template Instances disposent d'un ensemble de champs qui peuvent être configurés pour correspondre au comportement désiré.
En d'autres termes, les Template Types représentent une capacité de capteur qui permet de nouvelles télémétries et détections, et leur comportement en cours d'exécution est configuré dynamiquement par un Template Instance (c'est-à-dire un Rapid Response Content).
Rapid Response Content fournit une visibilité et des détections sur le capteur sans qu'il soit nécessaire de modifier le...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.
Envoyé par Mathis Lucas
C'est le ba-ba niveau sécurité. C'est bien des bonnes pratiques, mais ça ne résoud pas le problème de fond. L'accès au noyau doit-être "sécurisé", point. Et le meilleur moyen, c'est d'en interdire l'accès. Au minimum, les sociétés ayant besoin de cet accès doivent travailler en "trés" étroite collaboration avec une équipe de Microsoft. Equipe dont ce serait la spécialité et l'unique but.
C'est dit juste en dessous:
Et comment savoir si ce "partenaire" a ignoré les SDP ? Une fois une panne découverte ? Parce que compter sur la "transparence et la responsabilité", c'est bien beau, mais ça n'êmpéchera pas une nouvelle catastrophe de se produire. 
Quel est votre avis sur le sujet ?
