Les problèmes de cybersécurité que nous ne pouvons ignorer en 2022

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

‍

Ces deux dernières années ont été en quelque sorte un véritable baptême par le feu pour tout le monde, mais le plan de cybersécurité de la plupart des organisations a été mis à rude épreuve, car beaucoup d'entre nous ont adopté un modèle de travail à distance pratiquement du jour au lendemain. Nous avons vraiment dû passer à la vitesse supérieure et nous adapter en tant qu'industrie, surtout à la suite de menaces désespérées provoquant une hausse de 300 % des cybercrimes signalés depuis le début de la pandémie.

Nous avons tous tiré quelques leçons, et je suis rassuré de constater que non seulement la cybersécurité générale est prise plus au sérieux, mais aussi la sécurité et la qualité des logiciels au niveau du code. Décret exécutif 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 violation massive de SolarWinds. L'idée que nous devons tous nous préoccuper davantage de la sécurité, et les efforts visant à réduire les vulnérabilités grâce à une sensibilisation mesurable à la sécurité occupent certainement une place plus importante dans la conversation.

Cela dit, lorsqu'il s'agit de lutter contre les cybercriminels, nous devons rester aussi en phase que possible avec eux, en préemptant leurs terrains de jeu dans un esprit préventif.

Voici où je pense qu'ils pourraient commencer à faire des vagues au cours de la prochaine année :

Le métaverse est une nouvelle surface d'attaque

Le métaverse est peut-être la prochaine évolution d'Internet, mais une transformation similaire ne s'est pas encore matérialisée dans la manière dont la plupart des industries abordent la sécurisation des logiciels et des environnements numériques.

Bien que les pièges généraux en matière de cybersécurité, tels que les escroqueries par hameçonnage, soient inévitables (et probablement nombreux alors que tout le monde trouve ses marques dans le métaverse), l'infrastructure et les appareils qui rendent possible ce monde virtuel immersif 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 constituent la nouvelle passerelle vers des montagnes de données utilisateur. La sécurité des systèmes embarqués de plus en plus complexes est requise pour sécuriser les gadgets IoT, et le nouveau monde de la réalité virtuelle et augmentée grand public ne fait pas exception. Comme nous l'avons vu avec l'exploit Log4Shell, de simples erreurs au niveau du code peuvent se transformer en une passe secrète pour les acteurs de la menace, et dans une réalité simulée, chaque mouvement crée des données susceptibles d'être volées.

Bien qu'il n'en soit qu'à ses balbutiements, un métaverse réussi nécessitera l'adoption pratique de la crypto-monnaie (et pas seulement la thésaurisation aléatoire de la dernière pièce mème) et d'objets de valeur tels que les NFT, ce qui signifie que notre richesse, notre identité, nos données et nos moyens de subsistance réels sont potentiellement ouverts à un nouveau « Far West » qui peut mettre les gens en danger. Avant que nous, les ingénieurs, ne commencions à nous lancer dans des fonctionnalités et des améliorations épiques, minimiser cette nouvelle et vaste surface d'attaque à partir de zéro devrait être une priorité.

La législation à la suite de Log4Shell

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

Cette attaque de type « jour zéro » est parmi les pires jamais enregistrées, avec des comparaisons entre Log4Shell et la vulnérabilité dévastatrice Heartbleed OpenSSL qui est toujours exploité plus de six ans plus tard. Si l'on se fie à cette chronologie, nous serons confrontés à une gueule de bois Log4Shell pendant longtemps. Il est clair que malgré les leçons tirées de Heartbleed, du moins en termes de nécessité de déployer et d'implémenter 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 s'avérer extrêmement difficile et bureaucratique, nécessitant une documentation et une mise en œuvre interservices. Bien souvent, les départements informatiques et les développeurs ne disposent pas d'une connaissance encyclopédique de toutes les bibliothèques, composants et outils utilisés, et sont entravés par des calendriers de déploiement stricts visant à minimiser les interruptions et les temps d'arrêt des applications. Cette méthode de travail a de bonnes raisons (à savoir : personne ne veut lancer une clé et casser quelque chose), mais patcher trop lentement, c'est se contenter d'une solution.

Tout comme le Attaque SolarWinds a changé la donne en matière de chaîne d'approvisionnement logicielle. Je prédis qu'il en sera de même à la suite de Log4Shell. Bien qu'il existe déjà des mandats et des recommandations en matière de gestion des correctifs dans certaines industries critiques, la généralisation de la législation est une autre histoire. La sécurité logicielle préventive sera toujours la meilleure chance d'éviter l'application de correctifs de sécurité urgents, mais les meilleures pratiques en matière de sécurité stipulent que l'application de correctifs est une mesure prioritaire non négociable. Je pense que ce sera un sujet brûlant et qu'il donnera lieu à des recommandations pas si subtiles pour corriger rapidement et souvent.

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

Le nouveau Top 10 de l'OWASP en 2021 a connu quelques nouveautés importantes, ainsi qu'une surprise : les vulnérabilités liées à l'injection sont passées de la première place à une modeste troisième place. Ces nouveaux ajouts constituent en quelque sorte la « deuxième étape » du parcours des développeurs en matière de codage sécurisé et de meilleures pratiques de sécurité, et malheureusement, la plupart ne sont pas équipés pour avoir un impact positif sur la réduction des risques dans ce domaine à moins d'être correctement formés.

Nous savons depuis longtemps que les développeurs doivent posséder des compétences en matière de sécurité si nous voulons lutter contre les bogues de sécurité courants dans le code, et les organisations répondent mieux au principe de prévention piloté par les développeurs. Cependant, avec Conception peu sécurisée se classant dans le Top 10 de l'OWASP et constituant une catégorie de problèmes de sécurité architecturale plutôt qu'un type de bogue de sécurité unique, les développeurs devront être poussés au-delà des bases une fois qu'ils les auront maîtrisés. Les environnements d'apprentissage qui couvrent la modélisation des menaces, idéalement avec le soutien de l'équipe de sécurité, permettent de réduire considérablement la pression une fois que les développeurs ont réussi à améliorer leurs compétences, mais dans l'état actuel des choses, il s'agit d'une lacune de connaissances importante pour la plupart des ingénieurs logiciels.

Pour y remédier, il faut « tout un village », et l'organisation peut jouer un rôle dans la création d'une culture de sécurité positive pour les développeurs, en suscitant leur curiosité sans perturber sérieusement leur flux de travail.