Les erreurs logicielles les plus dangereuses de 2019 : une nouvelle preuve que l'histoire se répète

Cet article a été publié à l'origine dans Information Security Buzzet a été repris par plusieurs autres médias. Il a été mis à jour pour syndication ici.

Vers la fin de l'année dernière, l'incroyable communauté de MITRE a publié sa liste des 25 erreurs logicielles les plus dangereuses du CWE qui ont affecté le monde en 2019. Cette liste n'est pas basée sur une opinion, elle est le résultat d'une analyse à multiples facettes utilisant le travail d'organisations telles que le NIST, ainsi que les données publiées sur les vulnérabilités et expositions communes (CVE). Afin de déterminer les "principales" failles, une note est attribuée en fonction de leur gravité, de leur exploitabilité et de leur prévalence dans les logiciels actuels. Ce n'est pas le genre de liste qui vous vaudra des éloges, c'est certain.

Cependant, contrairement à la majorité des bilans annuels, de nombreux participants à cette liste sont déjà apparus auparavant... encore et encore. S'il s'agissait du classement Billboard Hot 100, ce serait comme si Britney Spears"Baby One More Time" et les Backstreet Boys"I Want It That Way" apparaissaient chaque année depuis leur sortie initiale. Pourquoi ai-je choisi ces chansons ? Eh bien, elles ont environ vingt ans (vous vous sentez déjà vieux ?), tout comme certaines de ces dangereuses erreurs logicielles qui continuent de nous affliger en 2020 bien qu'elles aient été découvertes il y a plusieurs dizaines d'années.

Pourquoi les vieux bugs sont-ils encore si dangereux ? Ne savons-nous pas comment les corriger ?

Le numéro six de la liste actuelle de MITRE est le CWE-89, mieux connu sous le nom d'injection SQL (SQLi). La vulnérabilité SQLi a été découverte pour la première fois en 1998, à l'époque où beaucoup d'entre nous posaient encore leurs questions brûlantes à Asking Jeeves plutôt qu'à Google. Un correctif a été rendu public peu de temps après, et pourtant, cela reste l'une des techniques de piratage les plus utilisées en 2019. L'étude d'Akamai État des lieux de l'Internet d'Akamai a révélé que SQLi était le coupable de deux tiers de toutes les attaques d'applications web.

En termes de complexité, l'injection SQL est loin d'être un exploit de génie. Il s'agit d'une solution simple pour un développeur web , et nous savons sans hésitation comment empêcher cette vulnérabilité d'exposer des données précieuses à un attaquant... le problème est que pour de nombreux développeurs, même aujourd'hui, la sécurité n'est pas une priorité. C'était peut-être plus facile il y a vingt ans, mais vu le volume de logiciels créés aujourd'hui et à l'avenir, cela ne peut plus rester la norme.

Les développeurs travaillent dans un système défaillant (la plupart du temps).

Il est trop facile de s'asseoir et de blâmer les développeurs pour avoir produit un "mauvais" code. En réalité, leurs priorités sont très différentes de celles de l'équipe de sécurité. L'équipe de développement moyenne a pour mission de créer des logiciels beaux et fonctionnels aussi rapidement que possible. Le besoin insatiable de la société en logiciels fait que les équipes de développement sont déjà surchargées et que la sécurité n'est pas une considération primordiale ; après tout, n'est-ce pas la raison d'être des spécialistes de l'AppSec ? Les ingénieurs logiciels sont habitués à une relation quelque peu froide avec la sécurité - ils n'entendent parler d'eux qu'en cas de problèmes, et ces problèmes peuvent retarder la production de leur travail acharné.

De l'autre côté de la barrière, les spécialistes de l'AppSec en ont assez de réparer des erreurs vieilles de plusieurs dizaines d'années qui reviennent sans cesse dans chaque analyse et examen manuel du code. Ces spécialistes sont chers et rares, et leur temps est bien mieux employé à corriger des failles de sécurité complexes qu'à éliminer des bogues bien connus, encore et encore.

Il existe une culture tacite qui consiste à pointer du doigt ces équipes, mais elles ont (ou devraient avoir) le même objectif : des logiciels sûrs. Les développeurs évoluent dans un environnement qui leur donne rarement les meilleures chances de réussite en termes de codage sécurisé ; les meilleures pratiques en matière de sécurité sont rarement enseignées dans le cadre de leur formation supérieure, et la formation sur le tas est souvent beaucoup trop rare, voire totalement inefficace. L'accent n'est pas mis sur la sensibilisation à la sécurité et sur une formation approfondie et pertinente, ce qui se traduit par le coût astronomique de la correction de vieux bogues dans un code engagé, ainsi que par la menace imminente d'une atteinte à la réputation de l'entreprise.

Le facteur humain, alias "Pourquoi tous ces outils ne rendent-ils pas nos données plus sûres ?".

Un autre problème qui apparaît fréquemment est qu'en lieu et place de la formation, un vaste arsenal d'outils de sécurité est mis à contribution pour détecter les problèmes avant que le logiciel ne soit diffusé dans la nature. Les outils d'analyse et de protection des applications(SAST/DAST/RASP/IAST) peuvent certainement contribuer à sécuriser la production de logiciels, mais ils posent leurs propres problèmes. Le fait de s'en remettre entièrement à eux ne garantit pas la sécurité, car.. :

• Aucun outil ne peut détecter toutes les vulnérabilités, dans tous les cadres et dans tous les cas d'utilisation.
• Ils peuvent être lents, surtout lorsqu'ils fonctionnent en tandem pour fournir une analyse statique et dynamique du code.
• Les faux positifs restent un problème ; ils interrompent souvent la production et nécessitent un examen manuel inutile du code pour donner un sens aux alertes.
• Ils créent un faux sentiment de sécurité, en privant le codage de sécurité de toute priorité dans l'espoir que ces outils détecteront tous les problèmes.

Les outils vont certainement déceler des failles de sécurité qui peuvent être corrigées, mais vont-ils tout trouver ? Il est impossible de garantir un taux de réussite de 100 %, et il suffit à un pirate de laisser une porte ouverte pour s'introduire dans votre système et vous gâcher la vie.

Heureusement, de nombreuses organisations prennent conscience du facteur humain en jeu dans les vulnérabilités des logiciels. La plupart des développeurs ne sont pas formés de manière adéquate à la codification sécurisée, et leur sensibilisation générale à la sécurité est faible. Pourtant, ils se trouvent au tout début du cycle de développement des logiciels et sont les mieux placés pour empêcher les vulnérabilités de se frayer un chemin jusqu'au code validé. S'ils codaient de manière sécurisée dès le départ, ils constitueraient les premières lignes de défense contre les cyberattaques dévastatrices qui nous coûtent des milliards chaque année.

Les développeurs doivent avoir la possibilité de s'épanouir, grâce à une formation qui parle leur langue, qui soit adaptée à leur travail et qui les incite à s'intéresser activement à la sécurité. Un code sans bogue devrait être un motif de fierté, tout comme la création d'un produit fonctionnellement génial vous vaudra le respect de vos pairs.

Un programme de sécurité moderne devrait être une priorité pour les entreprises.

Les équipes de développement ne peuvent pas se prendre en main et mettre en place une sensibilisation positive à la sécurité dans l'ensemble de l'entreprise. Elles auront besoin des outils, des connaissances et du soutien nécessaires pour intégrer la sécurité dans le processus de développement des logiciels dès le début.

Les anciennes méthodes de formation ne fonctionnent manifestement pas si la liste de MITRE présente toujours autant de bogues de sécurité, alors essayez quelque chose de nouveau. Recherchez des solutions de formation qui sont :

• Les développeurs aiment apprendre par la pratique et non pas en regardant des vidéos où l'on parle à tort et à travers.
• Pertinent ; ne les obligez pas à suivre une formation en C# s'ils utilisent Java tous les jours.
• Engageant ; l'apprentissage par petits bouts est facile à digérer et permet aux développeurs de continuer à développer leurs connaissances antérieures.
• Mesurables ; ne vous contentez pas de cocher une case et de passer à autre chose. Veillez à ce que la formation soit efficace et créez des voies d'amélioration.
• Amusant ; regardez comment vous pouvez sensibiliser à la sécurité tout en soutenant une culture de sécurité positive, et comment cela peut créer un environnement d'équipe cohésif.

La sécurité devrait être une priorité absolue pour tous les membres de l'organisation, le RSSI étant visible et transparent quant aux efforts déployés à tous les niveaux pour assurer la sécurité de nos données. Qui a envie d'entendre la même chanson à répétition ? Il est temps de prendre au sérieux l'élimination des vieux bogues pour de bon.