Les erreurs logicielles les plus dangereuses de 2019 : quand l'histoire se répète

Cet article est initialement paru dans Information Security Buzz, et a été repris par plusieurs autres médias. Il a été mis à jour pour une 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 (CWE Top 25) ayant affecté le monde en 2019. Cette liste ne repose pas sur des opinions, mais sur une analyse multidimensionnelle utilisant les travaux d'organisations comme le NIST, ainsi que les données publiques des vulnérabilités et expositions communes (CVE). Pour déterminer les failles « majeures », un score est attribué en fonction de leur gravité, de leur exploitabilité et de leur prévalence dans les logiciels actuels. Ce n'est certainement pas le genre de classement dont on tire une quelconque fierté.

Cependant, contrairement à la majorité des bilans annuels, bon nombre des éléments de cette liste sont déjà apparus par le passé... encore et encore. Si c'était le classement du Billboard Hot 100, ce serait comme si Baby One More Time de Britney Spears et I Want It That Way des Backstreet Boys figuraient au classement chaque année depuis leur sortie initiale. Pourquoi ai-je choisi ces chansons ? Eh bien, elles ont environ vingt ans (ça ne nous rajeunit pas, n'est-ce pas ?), tout comme certaines de ces erreurs logicielles dangereuses qui continuent de nous tourmenter en 2020, bien qu'elles aient été découvertes il y a des décennies.

Pourquoi ces vieux bugs sont-ils toujours aussi dangereux ? Ne savons-nous pas comment les corriger ?

La sixième place de la liste actuelle de MITRE est occupée par CWE-89, mieux connue sous le nom d'injection SQL (SQLi). La vulnérabilité SQLi a été découverte pour la première fois en 1998, à une époque où beaucoup d'entre nous posaient encore leurs questions brûlantes à Ask Jeeves plutôt qu'à Google. Un correctif a été rendu public peu après, et pourtant, cela reste l'une des techniques de piratage les plus utilisées en 2019. Le rapport State of the Internet d'Akamai a révélé que l'injection SQL était responsable des deux tiers de toutes les attaques contre les applications web.

En termes de complexité, l'injection SQL est loin d'être une exploitation de génie. C'est une correction simple pour un développeur web, et nous savons sans aucune 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 aujourd'hui encore, la sécurité n'est pas une priorité. C'était peut-être plus facile il y a vingt ans, mais avec le volume considérable 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 bien trop facile de rester les bras croisés et de blâmer les développeurs pour avoir livré du « mauvais » code. La vérité est que leurs priorités diffèrent radicalement de celles de l'équipe de sécurité. On demande à une équipe de développement classique de créer des logiciels beaux et fonctionnels le plus rapidement possible. Le besoin insatiable de logiciels de la société garantit que les équipes de développement sont déjà surchargées, et la sécurité n'est pas une considération première ; après tout, n'est-ce pas pour cela que les spécialistes de la sécurité applicative (AppSec) existent ? Les ingénieurs logiciels sont habitués à une relation quelque peu glaciale avec la sécurité : ils n'entendent parler d'eux que lorsque des problèmes surviennent, et ces problèmes peuvent retarder la production de leur travail acharné.

De l'autre côté de la barrière, les spécialistes AppSec en ont assez de corriger des erreurs vieilles de plusieurs décennies qui continuent de surgir à chaque analyse et revue de code manuelle. Ces spécialistes sont coûteux et rares, et leur temps serait bien mieux employé sur des failles de sécurité complexes plutôt que d'éliminer sans cesse des bugs bien connus.

Il existe une culture tacite de rejet de la faute entre ces équipes, alors qu'elles ont (ou devraient avoir) le même objectif : des logiciels sécurisés. Les développeurs travaillent dans un environnement qui leur donne rarement les meilleures chances de réussir en matière de codage sécurisé ; les bonnes pratiques de sécurité sont rarement enseignées dans le cadre de leur formation supérieure, et la formation en entreprise est souvent trop peu fréquente ou totalement inefficace. Il y a un manque flagrant d'accent sur la sensibilisation à la sécurité et sur une formation approfondie et pertinente, ce qui entraîne un coût astronomique pour corriger les vieux bugs dans le code déjà validé, sans parler de la menace imminente d'une violation de données dévastatrice pour la réputation.

Le facteur humain, ou « Pourquoi tous ces outils ne rendent-ils pas nos données plus sûres ? »

Un autre problème fréquent est qu'au lieu de former les équipes, on déploie un vaste arsenal d'outils de sécurité pour détecter les problèmes avant que le logiciel ne soit mis en circulation. La gamme d'outils d'analyse et de protection des applications (SAST/DAST/RASP/IAST) peut certainement aider à la production de logiciels sécurisés, mais ils comportent leurs propres problèmes. S'y fier entièrement ne garantit pas la sécurité, car :

• Aucun outil « unique » ne peut analyser chaque vulnérabilité, dans chaque framework, pour chaque cas d'utilisation
• Ils peuvent être lents, surtout lorsqu'ils sont utilisés en tandem pour fournir à la fois une analyse de code statique et dynamique
• Les faux positifs restent un problème ; ils interrompent souvent la production et nécessitent une revue de code manuelle inutile pour comprendre les alertes
• Ils créent un faux sentiment de sécurité, reléguant le codage sécurisé au second plan dans l'attente que ces outils détectent les problèmes.

Les outils découvriront certainement des failles de sécurité qui pourront être corrigées, mais trouveront-ils tout ? Un taux de réussite de 100 % est impossible à garantir, et il suffit d'une seule porte laissée ouverte à un attaquant pour qu'il s'infiltre et gâche vraiment votre journée.

Heureusement, de nombreuses organisations prennent conscience du facteur humain dans les vulnérabilités logicielles. La plupart des développeurs ne sont pas correctement formés au codage sécurisé et leur sensibilisation globale à la sécurité est faible. Cependant, ils se trouvent au tout début du cycle de vie du développement logiciel et sont idéalement placés pour empêcher les vulnérabilités de se retrouver dans le code validé. S'ils codaient de manière sécurisée dès le départ, ils constitueraient la première ligne de défense contre des cyberattaques dévastatrices qui nous coûtent des milliards chaque année.

Les développeurs doivent avoir la chance de s'épanouir, avec une formation qui parle leur langage, qui est pertinente pour leur travail et qui les enthousiasme activement pour la sécurité. Un code sans bug devrait être une source de fierté, tout comme le fait de construire quelque chose de fonctionnellement génial vous vaudra le respect de vos pairs.

Un programme de sécurité moderne doit être une priorité commerciale.

Les équipes de développement ne peuvent pas s'améliorer seules et instaurer une véritable culture de la sécurité à l'échelle de l'entreprise. Elles ont besoin des outils, des connaissances et du soutien nécessaires pour intégrer la sécurité au processus de développement logiciel dès le départ.

Les anciennes méthodes de formation ne fonctionnent manifestement plus, comme en témoigne la persistance de nombreuses failles de sécurité classiques dans la liste du MITRE. Il est temps d'innover. Privilégiez des solutions de formation qui sont :

• Pratiques ; les développeurs préfèrent « apprendre en faisant » plutôt que de regarder des vidéos magistrales.
• Pertinentes ; inutile de les former au C# s'ils utilisent Java au quotidien.
• Engageantes ; un apprentissage par modules courts est facile à assimiler et permet aux développeurs de consolider leurs acquis.
• Mesurables ; ne vous contentez pas de cocher une case. Assurez-vous de l'efficacité de la formation et créez des parcours de progression.
• Ludiques ; découvrez comment renforcer la sensibilisation à la sécurité tout en favorisant une culture positive et en créant une dynamique d'équipe soudée.

La sécurité doit être une priorité absolue pour tous au sein de l'organisation, avec un RSSI visible et transparent sur les efforts déployés à chaque niveau pour mieux protéger nos données. Après tout, qui veut entendre le même discours en boucle ? Il est temps de prendre les choses au sérieux et d'éliminer définitivement ces vieilles vulnérabilités.