De nombreux articles ont été publiés concernant l’incident récent de Crowdstrike. Plutôt que de se concentrer sur le passé (vous pouvez consulter les détails ici), il est essentiel de se demander comment nous pouvons nous préparer pour l’avenir. Nous avons interrogé nos analystes experts sur les mesures concrètes que les organisations peuvent adopter.

Ne faites pas confiance à vos fournisseurs

Cette affirmation peut sembler sévère, mais elle est nécessaire. Alors que nous appliquons le principe du zéro confiance en matière de réseaux et de gestion des accès, nous avons tendance à croire que les fournisseurs de logiciels et de services sont infaillibles. La sécurité repose sur la perméabilité de la surface d’attaque globale : tout comme l’eau trouve un chemin, le risque aussi.

Crowdstrike était autrefois un leader dans le secteur, et sa réputation était solide. Les organisations pensent souvent : « C’est un fournisseur de sécurité, donc nous pouvons lui faire confiance. » Mais comme le dit le proverbe, « il ne faut pas faire d’hypothèses ». Aucun fournisseur, surtout dans le domaine de la sécurité, ne devrait bénéficier d’un traitement de faveur.

Il est à noter que la déclaration de Crowdstrike selon laquelle cet événement n’était pas un incident de sécurité a complètement raté le sujet. Quelle qu’en soit la cause, l’impact a été une interruption de service, entraînant des dommages tant commerciaux que réputationnels.

Considérez chaque mise à jour avec méfiance

Les correctifs de sécurité ne sont pas toujours traités de la même manière que les autres mises à jour. Ils peuvent être déclenchés ou demandés par les équipes de sécurité plutôt que par les opérations, et peuvent être perçus comme plus urgents. Cependant, il n’existe pas de mise à jour mineure en matière de sécurité ou d’opérations, comme le savent ceux qui ont déjà rencontré des problèmes avec un correctif.

Chaque mise à jour doit être examinée, testée et déployée de manière à gérer le risque. Une bonne pratique consiste à tester d’abord sur un échantillon réduit de machines, puis à procéder à un déploiement plus large, par exemple via un environnement de test ou une installation limitée. Si cela n’est pas possible pour une raison quelconque (peut-être contractuelle), considérez que vous travaillez à vos risques et périls jusqu’à ce qu’un délai suffisant soit écoulé.

Par exemple, bien que le correctif de Crowdstrike ait été obligatoire, certaines organisations ont réussi à bloquer la mise à jour en utilisant des paramètres de pare-feu. Une entreprise a utilisé sa plateforme SSE pour bloquer les serveurs de mise à jour une fois qu’elle a identifié le mauvais correctif. Grâce à un bon système d’alerte, cela a pris environ 30 minutes pour que l’équipe SecOps le reconnaisse et le déploie.

Une autre a limité les mises à jour de Crowdstrike à 100 Mo par minute ; elle n’a été touchée que par six hôtes et 25 points de terminaison avant de réduire ce chiffre à zéro.

Réduisez les points de défaillance uniques

Autrefois, la résilience était assurée par la duplication de systèmes spécifiques, le fameux « 2N+1 » où N représente le nombre de composants. Avec l’avènement du cloud, nous avons évolué vers l’idée que toutes les ressources sont éphémères, ce qui nous amène à ne plus nous soucier de ce genre de problème. Ce n’est pas vrai.

Posez-vous la question : « Que se passe-t-il si cela échoue ? » où « cela » peut désigner n’importe quel élément de l’architecture informatique. Par exemple, si vous choisissez de travailler avec un seul fournisseur de cloud, examinez les dépendances spécifiques : s’agit-il d’une machine virtuelle unique ou d’une région ? Dans ce cas, le problème de Microsoft Azure était limité au stockage dans la région centrale, par exemple. Pour être clair, cela doit également s’appliquer à l’agent de détection et de réponse lui-même.

Dans tous les cas, avez-vous un autre endroit vers lequel basculer si « cela » ne fonctionne plus ? Une duplication complète est (largement) impossible dans des environnements multi-cloud. Une meilleure approche consiste à définir quels systèmes et services sont critiques pour l’entreprise en fonction du coût d’une interruption, puis à investir dans des moyens de réduire les risques. Considérez cela comme une assurance ; une dépense nécessaire.

Considérez les sauvegardes comme une infrastructure critique

Chaque couche d’infrastructure de sauvegarde et de récupération est essentielle pour l’entreprise et doit être renforcée autant que possible. À moins que les données ne soient présentes à trois endroits différents, elles ne sont pas protégées, car si vous n’avez qu’une seule sauvegarde, vous ne saurez pas quelles données sont correctes ; de plus, l’échec se produit souvent entre l’hôte et la sauvegarde en ligne, donc vous avez également besoin d’une sauvegarde hors ligne.

L’incident de Crowdstrike a mis en lumière les entreprises qui manquaient d’une base de capacité de basculement et de récupération pour les systèmes critiques basés sur des serveurs. De plus, vous devez avoir confiance que l’environnement que vous mettez en place est « propre » et résilient en soi.

Dans cet incident, un problème courant était que les clés de chiffrement Bitlocker étaient stockées dans une base de données sur un serveur « protégé » par Crowdstrike. Pour atténuer cela, envisagez d’utiliser un ensemble complètement différent d’outils de sécurité pour la sauvegarde et la récupération afin d’éviter des vecteurs d’attaque similaires.

Planifiez, testez et révisez les processus d’échec

La récupération après sinistre (et c’était un désastre !) n’est pas une opération ponctuelle. Il peut sembler lourd de penser constamment à ce qui pourrait mal tourner, alors ne le faites pas – mais peut-être qu’une préoccupation trimestrielle serait bénéfique. Effectuez une évaluation approfondie des points faibles de votre infrastructure numérique et de vos opérations, et cherchez à atténuer les risques.

Comme l’a souligné une discussion, tous les risques sont des risques commerciaux, et le conseil d’administration est là pour arbitrer la gestion des risques. Il est de la responsabilité de chacun de communiquer les risques et leurs implications commerciales – en termes financiers – au conseil. Si le conseil choisit d’ignorer ces risques, alors il a pris une décision commerciale comme une autre.

Les domaines de risque mis en évidence dans ce cas concernent les risques associés aux mauvais correctifs, aux types d’automatisation inappropriés, à une confiance excessive envers les fournisseurs, à un manque de résilience dans la gestion des secrets (c’est-à-dire, les clés Bitlocker) et à l’absence de tests des plans de récupération pour les serveurs et les dispositifs périphériques.

Optez pour une automatisation résiliente

La situation de Crowdstrike a illustré un dilemme : nous ne pouvons pas faire entièrement confiance aux processus automatisés. La seule façon de gérer la complexité technologique est par l’automatisation. L’absence d’une solution automatisée a été un élément majeur de l’incident, car cela a nécessité que les entreprises « touchent manuellement » chaque appareil, à l’échelle mondiale.

La solution consiste à intégrer des humains et d’autres technologies dans les processus aux bons moments. Crowdstrike a déjà reconnu l’insuffisance de ses processus de test de qualité ; ce n’était pas un correctif complexe, et il aurait probablement été identifié comme défectueux s’il avait été correctement testé. De même, toutes les organisations doivent s’assurer que leurs processus de test sont à la hauteur.

Les technologies émergentes comme l’IA et l’apprentissage automatique pourraient aider à prédire et à prévenir des problèmes similaires en identifiant les vulnérabilités potentielles avant qu’elles ne deviennent problématiques. Elles peuvent également être utilisées pour créer des données de test, des scripts, etc., afin de maximiser la couverture des tests. Cependant, si elles sont laissées à fonctionner sans surveillance, elles pourraient également devenir partie intégrante du problème.

Révisez la diligence raisonnable des fournisseurs

Ce incident a mis en évidence la nécessité de revoir et de « tester » les relations avec les fournisseurs. Pas seulement en termes de services fournis, mais aussi d’arrangements contractuels (et de clauses de recours pour vous permettre de demander des dommages-intérêts) en cas d’incidents inattendus et, en effet, de la manière dont les fournisseurs réagissent. Peut-être que Crowdstrike sera davantage mémorisé pour la manière dont l’entreprise, et son PDG George Kurtz, ont réagi que pour les problèmes causés.

Il ne fait aucun doute que des leçons continueront d’être tirées. Peut-être devrions-nous avoir des organismes indépendants pour auditer et certifier les pratiques des entreprises technologiques. Peut-être devrait-il être obligatoire pour les fournisseurs de services et les éditeurs de logiciels de faciliter la transition ou la duplication des fonctionnalités, plutôt que d’adopter les approches de jardin clos qui prédominent aujourd’hui.

Dans l’ensemble, l’adage ancien s’applique : « Trompez-moi une fois, honte à vous ; trompez-moi deux fois, honte à moi. » Nous savons pertinemment que la technologie est faillible, mais nous espérons à chaque nouvelle vague qu’elle est devenue d’une certaine manière immunisée contre ses propres risques et l’entropie de l’univers. Avec le nirvana technologique reporté indéfiniment, nous devons assumer les conséquences.