En tant qu’architecte en chef de la sécurité de Tanium, Ryan Kazanciyan a été témoin des processus de réponse internes dans des dizaines d’entreprises à travers le monde à la suite de l’attaque par rançongiciel WannaCry. Son plus grand enseignement ? La résistance institutionnalisée au changement, et non la négligence simple, est l’une des principales raisons pour lesquelles tant d’entreprises ont été laissées vulnérables. Voici ce que vous pouvez faire pour y remédier.
(Image: Arek Socha / Pixabay)
Alors que nous regardons le cercle de blâmes se développer à la suite de l’attaque par rançongiciel WannaCry, il est naturel de se demander pourquoi les victimes ont été si lentes à mettre en œuvre des protections facilement disponibles. Un correctif qui aurait empêché cette épidémie était disponible depuis deux mois. Le logiciel malveillant a exploité une fonctionnalité Windows qui était obsolète depuis quatre ans. Ce qui est souvent négligé, c’est que la résistance institutionnalisée au changement, et non la négligence simple, est l’une des principales raisons pour lesquelles tant d’entreprises ont été laissées vulnérables.
Au cours de la semaine passée, j’ai eu l’occasion d’avoir un aperçu de certains des processus de réponse internes dans des dizaines d’entreprises à travers le monde à la suite de l’attaque par rançongiciel WannaCry. J’ai vu des déconnexions trop fréquentes entre la perception et la réalité.
Commençons par la déconnexion la plus flagrante : de nombreuses organisations fonctionnaient en supposant que la majorité de leurs systèmes avaient été corrigés. Au lieu de cela, ils ont découvert que le pourcentage d’ordinateurs sensibles dans leur flotte était à deux chiffres. D’autres n’avaient aucun moyen de valider si les systèmes avaient été redémarrés, ou si d’autres modifications de configuration atténuantes avaient été mises en place ou prises en vigueur. Et d’autres ont toujours hésité à « tirer le déclencheur » des correctifs, car ils n’étaient pas sûrs de pouvoir détecter rapidement des conséquences imprévues ou d’être en mesure d’inverser les modifications si nécessaire.
La situation n’est pas unique à l’attaque WannaCry. Même alors que la sécurité informatique mondiale annuelle approche les 100 milliards USD en 2017, les entreprises continuent de lutter contre les tâches de gestion des systèmes de base, telles que l’application de correctifs, qui sont essentielles à ce que l’on appelle l’hygiène de sécurité. Pour comprendre pourquoi c’est le cas, nous devons d’abord examiner comment la plupart des organisations informatiques fonctionnent.
Au cours de la dernière décennie, les développeurs de logiciels ont adopté le mouvement DevOps et les méthodologies dites agiles. Ces approches mettent l’accent sur le développement, les tests et la livraison itératifs et rapides de solutions dans l’entreprise. Cependant, les processus d’ingénierie et de contrôle des modifications dans de nombreux domaines des opérations informatiques et de sécurité sont restés relativement archaïques et résistants à l’évolution. Il s’agit d’un conflit de philosophies : changement rapide, incrémentiel, automatisé par rapport à des courses méthodiques, planifiées et vérifiées.
WannaCry soulève de graves problèmes organisationnels
Il existe des raisons très réelles et pratiques pour lesquelles les opérations informatiques et de sécurité sont résistantes au changement. La plupart des infrastructures informatiques constituent un corbeille de technologies existantes et modernes, truquées pour fonctionner ensemble au fil du temps. Selon Frost & Sullivan, l’organisation moyenne exécute quatre à six systèmes d’exploitation sur les endpoints et quatre à sept systèmes d’exploitation différents sur les serveurs. Des centaines d’applications critiques pour l’entreprise, certaines plus sensibles aux modifications de la couche du système d’exploitation que d’autres, peuvent s’exécuter sur ces plateformes. Et la responsabilité opérationnelle de la gestion de toute cette infrastructure est souvent très cloisonnée, avec l’informatique de l’utilisateur final, l’administration des serveurs et la supervision des applications, le tout divisé entre de nombreuses équipes qui ne se déplacent pas toujours à la même cadence. L’ajout de sous-traitants dans le mix introduit une complexité supplémentaire. Et aucun individu ou aucune équipe ne veut être celui dont les efforts d’application de correctifs font tomber un système crucial.
Lorsque les exigences commerciales exigent une disponibilité ininterrompue du système, il est facile de comprendre pourquoi les entreprises adoptent une approche prudente sur certains types de changements informatiques. Et, pour être équitables, les processus modernes de contrôle des changements offrent tous des dispositions pour gérer les urgences. Mais même lorsque l’urgence de l’incident WannaCry exigeait la flexibilité d’apporter des changements, de nombreuses organisations sont restées limitées par leurs opérations de sécurité et leur technologie de gestion des systèmes. Cela démontre un cercle vicieux : en l’absence de capacité technique à effectuer des changements de manière fiable et rapide et à surveiller les résultats à grande échelle, les personnes ajoutent un « glisser » sous la forme d’une plus grande délibération, d’un processus et d’un consensus. Cela nuit encore à leur agilité et limite l’efficacité des solutions dans lesquelles ils ont investi.
Malheureusement, le correctif qui aurait pu empêcher WannaCry de se propager avait le mélange « parfait » d’attributs pour ralentir son adoption :
- Elle a affecté presque toutes les versions de Windows, ce qui signifie plus de rôles et de types de système nécessitant des tests.
- Elle a nécessité un redémarrage (tous les correctifs ne le font pas), nécessitant une coordination du calendrier pour minimiser l’impact commercial.
- Il n’a été initialement publié pour Windows XP et Server 2003 qu’après l’épidémie de WannaCry. Bien que les deux systèmes d’exploitation soient en fin de vie, ils restent présents dans de nombreux environnements. Leur nombre diminue : le NHS n’a signalé qu’environ 5 % de ses hôtes inventoriés ont exécuté XP, par exemple, mais ces systèmes sont souvent utilisés pour prendre en charge les appareils existants critiques.
Dans le contexte de ces obstacles techniques et procéduraux, il n’est pas surprenant que WannaCry ait eu un impact aussi dévastateur, en particulier sur des secteurs verticaux tels que les soins de santé.
La vérité effrayante est que WannaCry aurait pu être beaucoup, beaucoup pire. À la date de ce document, le logiciel malveillant « n’infectait » que quelques centaines de milliers de systèmes. En revanche, Conficker (qui a exploité une vulnérabilité Windows aussi répandue en 2008) s’est étendu à plus de 10 millions d’ordinateurs. De nombreuses organisations ont simplement eu la chance d’échapper aux mires des campagnes d’attaque initiales. Et pourtant, notre dépendance aux systèmes informatiques en 2017 signifie que les effets de cette attaque ont été beaucoup plus ressentis que d’autres qui l’ont précédée.
Les responsables informatiques doivent saisir cette opportunité pour favoriser la modernisation des processus et des technologies qui sous-tendent la gestion des systèmes et les opérations de sécurité, et non pas simplement se concentrer sur l’amélioration de la détection et de la réponse aux attaques. Lorsque de futures attaques échappent inévitablement à nos premières lignes de défense, une approche agile de l’hygiène de sécurité peut empêcher les infections dispersées à petite échelle de devenir la prochaine épidémie mondiale.
À propos de l’auteur : Dans son rôle d’architecte en chef de la sécurité de Tanium, Ryan Kazanciyan apporte plus de 14 ans d’expérience dans la réponse aux incidents, l’analyse médico-légale et les tests de pénétration. Ryan supervise la conception et la feuille de route des offres de réponse aux menaces de Tanium et dirige l’équipe de détection et de réponse aux endpoints (EDR) de Tanium. Avant de rejoindre Tanium, Ryan supervisait les efforts d’enquête et de remédiation chez Mandiant, en s’associant à des dizaines d’entreprises du Fortune 500 touchées par des attaques ciblées. Ryan a formé des centaines d’intervenants en cas d’incident en tant qu’instructeur pour Black Hat et l’équipe informatique du FBI. Il est un auteur contributeur pour « Incident Response and Computer Forensics 3rd Edition » (McGraw-Hill, 2014). Ryan travaille également comme consultant technique pour la série télévisée « M. Robot », où il collabore avec les écrivains et l’équipe de production pour concevoir les piratages décrits dans l’émission.
