Les enjeux de cybersécurité incontournables en 2022

Une version de cet article a été publiée dans Infosecurity Magazine. Il a été mis à jour et syndiqué ici.

‍

Les deux dernières années ont été une véritable épreuve du feu pour tout le monde, mais le plan de cybersécurité de la plupart des organisations a été mis à rude épreuve lorsque beaucoup d'entre nous ont été propulsés dans un modèle de travail à distance presque du jour au lendemain. Nous avons dû monter en puissance et nous adapter en tant qu'industrie, surtout face à des acteurs malveillants désespérés provoquant une hausse de 300 % des cybercrimes signalés depuis le début de la pandémie.

Nous avons tous tiré quelques leçons de cette période, et je suis rassuré de constater que la cybersécurité générale est prise plus au sérieux, tout comme la sécurité et la qualité des logiciels au niveau du code. Le décret présidentiel de Biden sur la sécurisation de la chaîne d'approvisionnement logicielle a mis en lumière des problèmes critiques, notamment à la suite de la cyberattaque massive contre SolarWinds. L'idée que nous devons tous nous soucier davantage de la sécurité, et travailler à réduire les vulnérabilités grâce à une sensibilisation mesurable à la sécurité, occupe désormais une place plus importante dans les débats.

Cela étant dit, pour lutter contre les cybercriminels, nous devons rester aussi proches d'eux que possible, en anticipant leurs terrains de jeu avec une approche préventive.

Voici les domaines où je pense qu'ils pourraient commencer à faire des vagues l'année prochaine :

Le métavers, une nouvelle surface d'attaque

Le métavers est peut-être la prochaine évolution d'Internet, mais une transformation similaire doit encore se concrétiser dans la manière dont la plupart des industries abordent la sécurisation des logiciels et des environnements numériques.

Si les pièges classiques de la cybersécurité, comme les tentatives de phishing, seront inévitables (et probablement nombreux le temps que chacun prenne ses marques dans le métavers), l'infrastructure et les appareils qui rendent ce monde virtuel immersif possible devront être sécurisés. Tout comme les smartphones nous ont aidés à vivre en ligne, les périphériques tels que les casques VR sont la nouvelle porte d'entrée vers des montagnes de données utilisateur. Une sécurité des systèmes embarqués de plus en plus complexe est nécessaire pour rendre les gadgets IoT sûrs, et le nouveau monde prometteur de la VR/AR grand public ne fait pas exception. Comme nous l'avons vu avec l'exploit Log4Shell, de simples erreurs au niveau du code peuvent devenir un laissez-passer pour les acteurs malveillants, et dans une réalité simulée, chaque mouvement génère des données susceptibles d'être volées.

Bien qu'il n'en soit qu'à ses débuts, un métavers réussi nécessitera une adoption pratique des cryptomonnaies (et pas seulement une accumulation aléatoire de la dernière pièce à la mode) ainsi que d'objets de valeur comme les NFT. Cela signifie que notre richesse, notre identité, nos données et nos moyens de subsistance dans la vie réelle sont potentiellement exposés à un nouveau « Far West » qui peut mettre les gens en danger. Avant que nous, ingénieurs, ne nous lancions tête baissée dans des fonctionnalités et des améliorations épiques, minimiser cette nouvelle et vaste surface d'attaque dès la conception devrait être une priorité.

La législation après Log4Shell

Pour les nombreux développeurs plongés dans le chaos, cherchant désespérément à savoir s'il existait des instances ou des dépendances associées à une version exploitable de l'outil de journalisation largement utilisé Log4j, je ne pense pas que la période des fêtes ait été très joyeuse.

Cette attaque zero-day figure parmi les pires jamais enregistrées, avec des comparaisons faites entre Log4Shell et la vulnérabilité dévastatrice Heartbleed d'OpenSSL, qui est toujours exploitée plus de six ans plus tard. Si cette chronologie nous sert de référence, nous devrons gérer les conséquences de Log4Shell pendant encore longtemps. Il est clair que même avec les leçons tirées de Heartbleed — du moins en ce qui concerne la nécessité de déployer et d'appliquer des correctifs le plus rapidement possible — de nombreuses organisations n'agissent tout simplement pas assez vite pour se protéger. Selon la taille de l'entreprise, l'application de correctifs peut être incroyablement difficile et bureaucratique, nécessitant une documentation et une mise en œuvre interservices. Très souvent, les départements informatiques et les développeurs n'ont pas une connaissance encyclopédique de toutes les bibliothèques, composants et outils utilisés, et sont freinés par des calendriers de déploiement stricts visant à minimiser les perturbations et les temps d'arrêt des applications. Il existe des raisons valables à cette méthode de travail (personne ne veut mettre des bâtons dans les roues et tout casser), mais appliquer des correctifs trop lentement, c'est s'exposer inutilement.

Tout comme l'attaque SolarWinds a changé la donne pour la chaîne d'approvisionnement logicielle, je prédis qu'il en sera de même après Log4Shell. Bien qu'il existe déjà des mandats et des recommandations de gestion des correctifs dans certaines industries critiques, une législation généralisée est une autre affaire. La sécurité logicielle préventive sera toujours notre meilleure chance d'éviter complètement les correctifs de sécurité urgents, mais les meilleures pratiques de sécurité dictent que le patching est une mesure prioritaire non négociable. Je pense que ce sera un sujet brûlant, menant à des recommandations explicites de corriger rapidement et fréquemment.

Plus d'accent sur la sécurité architecturale (et les développeurs ne sont pas prêts)

Le nouveau OWASP Top 10 2021 comportait des ajouts importants, ainsi qu'une surprise : les vulnérabilités par injection sont passées de la première place à une modeste troisième. Ces nouveaux ajouts témoignent d'une sorte de « deuxième étape » dans le parcours d'un développeur en matière de codage sécurisé et de bonnes pratiques de sécurité. Malheureusement, la plupart sont mal équipés pour réduire efficacement les risques sans une formation appropriée.

Nous savons depuis un certain temps que les développeurs doivent être compétents en sécurité si nous voulons combattre les bugs de sécurité courants dans le code, et les organisations répondent mieux au principe de prévention pilotée par les développeurs. Cependant, avec la conception non sécurisée (Insecure Design) qui fait son entrée dans le Top 10 de l'OWASP et qui représente une catégorie de problèmes de sécurité architecturale plutôt qu'un simple type de bug, les développeurs devront aller au-delà des bases une fois celles-ci maîtrisées. Les environnements d'apprentissage qui couvrent la modélisation des menaces — idéalement avec le soutien de l'équipe de sécurité — soulagent considérablement la pression une fois que les développeurs sont formés, mais en l'état actuel, il s'agit d'un déficit de connaissances important pour la plupart des ingénieurs logiciels.

Contrer cela nécessite une approche collective, et l'organisation peut jouer un rôle en créant une culture de sécurité positive pour les développeurs, en stimulant leur curiosité sans perturber leur flux de travail.