En tant qu’architecte en chef de la sécurité chez Tanium, Ryan Kazanciyan a pu observer les processus de réaction internes mis en place dans des dizaines d’entreprises à travers le monde à la suite de l’attaque du rançongiciel WannaCry. Quelle a été sa principale leçon ? C'est la résistance institutionnelle au changement – et non une simple négligence – qui constitue l'une des principales raisons pour lesquelles tant d'entreprises se sont retrouvées vulnérables. Voici ce que vous pouvez faire pour y remédier.
(Image: Arek Socha / Pixabay)
Alors que nous voyons le cercle des reproches s'élargir à la suite de l'attaque du ransomware WannaCry, il est naturel de se demander pourquoi les victimes ont mis tant de temps à mettre en place des mesures de protection pourtant facilement accessibles. Un correctif qui aurait permis d'éviter cette épidémie était disponible depuis deux mois. Ce logiciel malveillant a exploité une fonctionnalité de Windows qui n'était plus prise en charge depuis quatre ans. Ce que l'on oublie souvent, c'est que c'est la résistance institutionnelle au changement – et non une simple négligence – qui constitue l'une des principales raisons pour lesquelles tant d'entreprises se sont retrouvées vulnérables.
Au cours de la semaine dernière, j'ai eu l'occasion d'avoir un aperçu de certains des processus de réaction internes mis en place dans des dizaines d'entreprises à travers le monde à la suite de l'attaque du rançongiciel WannaCry. J'ai constaté des décalages bien trop fréquents entre la perception et la réalité.
Commençons par le décalage le plus flagrant : de nombreuses organisations partaient du principe que la majorité de leurs systèmes avaient été mis à jour. Au contraire, ils ont découvert que le pourcentage d'ordinateurs vulnérables au sein de leur parc atteignait un chiffre à deux chiffres. D'autres n'avaient aucun moyen de vérifier si les systèmes avaient été redémarrés, ni si d'autres modifications de configuration visant à atténuer les risques avaient été mises en place ou étaient entrées en vigueur. D'autres encore hésitaient à « passer à l'action » pour mettre en œuvre ces corrections, car ils n'étaient pas certains de pouvoir détecter rapidement d'éventuelles conséquences imprévues, ni d'être en mesure d'annuler les modifications si nécessaire.
Cette situation n'est pas propre à l'attaque WannaCry. Alors même que les dépenses annuelles en matière de sécurité informatique à l'échelle mondiale s'élèvent à près de 100 milliards de dollars en 2017, les entreprises continuent de rencontrer des difficultés avec des tâches élémentaires de gestion des systèmes, telles que l'application de correctifs, qui sont essentielles à ce que l'on appelle l'« hygiène de sécurité ». Pour comprendre pourquoi il en est ainsi, il faut d'abord examiner le mode de fonctionnement de la plupart des services informatiques.
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 mise en œuvre itératifs et rapides de solutions au sein de l'entreprise. Cependant, les processus d'ingénierie et de gestion des changements dans de nombreux domaines des opérations informatiques et de sécurité sont restés relativement archaïques et résistent obstinément à toute évolution. C'est un choc entre deux philosophies : d'un côté, un changement rapide, progressif et automatisé ; de l'autre, des mesures de grande envergure, méthodiques, planifiées et validées.
WannaCry soulève de graves problèmes organisationnels
Il existe des raisons bien réelles et concrètes qui expliquent pourquoi les services informatiques et de sécurité sont réticents au changement. La plupart des infrastructures informatiques constituent un méli-mélo de technologies anciennes et modernes, bricolées au fil du temps pour fonctionner ensemble. Selon Frost & Sullivan, une entreprise utilise en moyenne quatre à six systèmes d'exploitation sur ses terminaux et quatre à sept systèmes d'exploitation différents sur ses serveurs. Des centaines d'applications essentielles à l'activité de l'entreprise – dont certaines sont plus sensibles aux modifications au niveau du système d'exploitation que d'autres – peuvent fonctionner sur ces plateformes. De plus, la responsabilité opérationnelle de la gestion de l'ensemble de cette infrastructure est souvent très compartimentée : l'informatique destinée aux utilisateurs finaux, l'administration des serveurs et la supervision des applications sont réparties entre de nombreuses équipes qui ne fonctionnent pas toujours au même rythme. L'intervention de sous-traitants et de prestataires externes vient ajouter une complexité supplémentaire. Et aucun individu ni aucune équipe ne souhaite être à l'origine d'une panne d'un système crucial à cause de ses efforts de correction.
Lorsque les exigences métier imposent une disponibilité ininterrompue des systèmes, on comprend aisément pourquoi les entreprises adoptent une approche prudente face à certains types de changements informatiques. Et, pour être honnête, tous les processus modernes de contrôle des modifications prévoient des dispositions pour la gestion des situations d'urgence. Mais même lorsque l'urgence liée à l'incident WannaCry exigeait une certaine souplesse pour apporter des modifications, de nombreuses organisations restaient limitées par leurs opérations de sécurité et leurs technologies de gestion des systèmes. Cela illustre un cercle vicieux : en l'absence de capacités techniques permettant de mettre en œuvre des changements de manière fiable et rapide et d'en suivre les résultats à grande échelle, les personnes créent des « freins » sous la forme d'une délibération, de procédures et d'un consensus accrus. Cela nuit encore davantage à leur agilité et limite l'efficacité des solutions dans lesquelles elles ont investi.
Malheureusement, le correctif qui aurait pu empêcher la propagation de WannaCry présentait la combinaison « parfaite » de caractéristiques susceptibles de freiner son adoption :
- Cela a concerné la quasi-totalité des versions de Windows, ce qui implique un plus grand nombre de rôles et de types de systèmes à tester.
- Cela a nécessité un redémarrage (ce qui n'est pas le cas de tous les correctifs), ce qui a impliqué une coordination des plannings afin de minimiser l'impact sur l'activité.
- À l'origine, il n'a été mis à disposition pour Windows XP et Server 2003 qu'après l'épidémie de WannaCry. Bien que ces deux systèmes d'exploitation soient arrivés en fin de vie, ils sont toujours présents dans de nombreux environnements. Leur nombre diminue – le NHS a par exemple indiqué que seuls environ 5 % des postes répertoriés dans son inventaire fonctionnaient sous XP –, mais ces systèmes sont souvent utilisés pour prendre en charge des équipements hérités essentiels.
Compte tenu de ces obstacles techniques et procéduraux, il n’est pas surprenant que WannaCry ait eu un impact aussi dévastateur, en particulier dans des secteurs tels que celui de la santé.
La vérité effrayante, c'est que WannaCry aurait pu avoir des conséquences bien, bien plus graves. À l'heure où nous écrivons ces lignes, ce logiciel malveillant n'a infecté « que » quelques centaines de milliers de systèmes. En revanche, Conficker (qui exploitait une faille de sécurité de Windows tout aussi répandue en 2008) s'est propagé à plus de 10 millions d'ordinateurs. De nombreuses organisations ont tout simplement eu la chance d'échapper à la ligne de mire des premières campagnes d'attaques. Et pourtant, notre dépendance vis-à-vis des systèmes informatiques au sein de la section 2017 fait que les conséquences de cette attaque ont été ressenties de manière bien plus vive que celles des attaques précédentes.
Les responsables informatiques doivent saisir cette opportunité pour mener à bien la modernisation des processus et des technologies qui sous-tendent la gestion des systèmes et les opérations de sécurité – et ne pas se contenter de se concentrer sur l'amélioration de la détection des attaques et de la réponse à celles-ci. Lorsque de futures attaques parviendront inévitablement à contourner nos premières lignes de défense, une approche agile en matière d'hygiène de sécurité permettra d'empêcher que des infections de faible ampleur et dispersées ne se transforment en une nouvelle épidémie mondiale.
À propos de l'auteur : En tant qu'architecte en chef de la sécurité chez Tanium, Ryan Kazanciyan apporte plus de 14 ans d'expérience dans les domaines de la gestion des incidents, de l'analyse forensic et des tests d'intrusion. Ryan supervise la conception et la feuille de route des offres de Tanium en matière de réponse aux menaces, et dirige l'équipe EDR (Endpoint Detection and Response) de Tanium. Avant de rejoindre Tanium, Ryan a supervisé les opérations d'enquête et de remédiation chez Mandiant, en collaboration avec des dizaines d'entreprises du classement Fortune 500 victimes d'attaques ciblées. En tant que formateur pour Black Hat et la brigade cybercriminalité du FBI, Ryan a formé des centaines de spécialistes de la gestion des incidents. Il est l'un des auteurs de l'ouvrage « Incident Response and Computer Forensics, 3e édition » (McGraw-Hill, p. 2014). Ryan travaille également en tant que consultant technique pour la série télévisée « Mr. Robot », où il collabore avec les scénaristes et l'équipe de production afin de concevoir les piratages informatiques mis en scène dans la série.
