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

Cet article a été initialement publié dans Buzz en matière de sécurité informatique, et a été reprise par plusieurs autres points de vente. Il a été mis à jour pour la syndication ici.

Vers la fin de l'année dernière, l'incroyable communauté de MITRE a publié sa liste des Les 25 erreurs logicielles les plus dangereuses du CWE qui a touché le monde en 2019. Cette liste n'est pas dictée par l'opinion, elle est le résultat d'une analyse à multiples facettes utilisant le travail d'organisations telles que NIST, ainsi que des données publiées sur les vulnérabilités et les expositions communes (CVE). Afin de déterminer les « principales » failles, un score est attribué 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 remportera des éloges positifs, c'est certain.

Cependant, contrairement à la plupart des résumés annuels, de nombreux participants figurant sur cette liste sont déjà apparus... à maintes reprises. S'il s'agissait du palmarès Billboard Hot 100, ce serait comme celui de Britney SpearsBébé encore une fois et les Backstreet BoysJe le veux comme ça paraissant chaque année depuis leur sortie initiale. Et pourquoi j'ai choisi ces chansons ? Eh bien, ils ont environ vingt ans (vous vous sentez vieux ?) , tout comme certaines de ces erreurs logicielles dangereuses qui continuent de nous affliger en 2020 malgré leur découverte il y a des décennies.

Pourquoi les vieux bugs sont-ils toujours aussi dangereux ? Ne savons-nous pas comment les réparer ?

Le numéro six sur la liste MITRE actuelle est 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 les plus pressantes à Jeeves au lieu de Google. Un correctif a été publié peu de temps après, et pourtant, cela reste l'une des techniques de piratage les plus utilisées en 2019. D'Akamai État de l'Internet un rapport a révélé que SQLi était le coupable dans les deux tiers des tous attaques d'applications Web.

En termes de complexité, l'injection SQL est loin d'être un exploit de génie. C'est une solution simple pour un développeur Web, et nous faire Sachez sans hésiter comment empêcher cette vulnérabilité d'exposer des données précieuses à un attaquant... Le problème, c'est que pour de nombreux développeurs, encore aujourd'hui, la sécurité n'est pas une priorité. Cela aurait peut-être été plus facile il y a vingt ans, mais compte tenu du volume considérable de logiciels créés aujourd'hui et à l'avenir, cela ne peut plus rester la norme.

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

Il est trop facile de rester les bras croisés et de reprocher aux développeurs de fournir du « mauvais » code. En vérité, leurs priorités sont très différentes de celles de l'équipe de sécurité. On demande à votre équipe de développement ordinaire de créer de beaux logiciels fonctionnels le plus rapidement possible. Les besoins insatiables de la société en matière de logiciels font que les équipes de développement sont déjà sollicité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 la sécurité des applications ? Les ingénieurs logiciels sont habitués à une relation quelque peu froide avec la sécurité : ils n'ont de nouvelles d'eux que lorsque des problèmes surviennent, et ces problèmes peuvent retarder la production de leur dur labeur.

De l'autre côté de la barrière, les spécialistes d'AppSec en ont assez de corriger des erreurs vieilles de plusieurs décennies qui apparaissent sans cesse à chaque scan et à chaque révision manuelle du code. Ces spécialistes sont chers et rares, et il est préférable de consacrer leur temps à des failles de sécurité complexes au lieu de corriger des bogues bien connus à l'infini.

Il existe une culture tacite du pointage du doigt entre ces équipes, mais elles ont (ou devraient avoir) le même objectif : sécuriser les logiciels. 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 leurs études supérieures, et la formation en cours d'emploi est souvent bien trop peu fréquente, 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 un coût astronomique lié à la correction d'anciens bogues dans du code validé, ainsi que la menace imminente d'une violation de données destructrice de réputation.

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

Un autre problème qui revient fréquemment est qu'à la place de la formation, un vaste arsenal d'outils de sécurité est utilisé pour détecter les problèmes avant que les logiciels ne soient publiés dans la nature. Les outils d'analyse et de protection des applications de la baie (SAST/DAST/RASP/IAST) peuvent certainement contribuer à la production sécurisée de logiciels, mais ils présentent leurs propres problèmes. Le fait de s'y fier totalement ne garantit pas la sécurité, car :

• Aucun outil « unique » ne peut détecter toutes les vulnérabilités, dans tous les frameworks et dans tous les cas d'utilisation
• Ils peuvent être lents, en particulier lorsqu'ils sont exécutés en tandem pour fournir une analyse de code statique et dynamique
• Les faux positifs continuent de poser problème ; ils interrompent souvent la production et nécessitent une révision manuelle inutile du code pour donner un sens aux alertes
• Ils créent un faux sentiment de sécurité, le codage sécurisé étant dévalorisé dans l'espoir que ces outils détecteront les problèmes éventuels.

Les outils permettront certainement de découvrir des failles de sécurité qui peuvent être corrigées, mais trouveront-ils tout ? Il est impossible de garantir un taux de réussite de 100 %, et un attaquant n'a besoin que d'une seule porte ouverte pour entrer et gâcher votre journée.

Heureusement, de nombreuses organisations prennent conscience du facteur humain en jeu dans vulnérabilités logicielles. La plupart des développeurs ne sont pas suffisamment formés au codage sécurisé et leur niveau de sensibilisation général à la sécurité est faible. Cependant, ils n'en sont qu'au tout début du cycle de vie du développement logiciel et occupent une position idéale pour empêcher les vulnérabilités de pénétrer dans le code validé. S'ils codaient de manière sécurisée dès le départ, ils seraient en première ligne 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 passionne activement pour la sécurité. Un code exempt de bogues devrait être une source de fierté, tout comme créer quelque chose de performant sur le plan fonctionnel vous permettra de gagner le respect de vos pairs.

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

Les équipes de développement ne peuvent pas se débrouiller seules et mettre en place une sensibilisation positive à la sécurité au sein de l'entreprise. Ils auront besoin des outils, des connaissances et de l'assistance appropriés pour intégrer la sécurité au processus de développement logiciel dès le début.

Les anciennes méthodes de formation ne fonctionnent clairement pas si la liste de MITRE contient toujours autant d'anciens bogues de sécurité, alors essayez quelque chose de nouveau. Recherchez des solutions de formation qui sont les suivantes :

• Pratique ; les développeurs adorent « apprendre par la pratique », au lieu de regarder des vidéos qui parlent
• Pertinent ; ne les forcez pas à s'entraîner en C# s'ils utilisent Java tous les jours
• Un apprentissage captivant et rapide est facile à assimiler et permet aux développeurs de continuer à s'appuyer sur leurs connaissances antérieures
• Mesurable ; ne vous contentez pas de cocher une case pour passer à autre chose. Garantir l'efficacité de la formation et créer des voies d'amélioration
• Amusant ; découvrez comment vous pouvez renforcer la sensibilisation à la sécurité en plus de favoriser une culture de sécurité positive, et comment cela peut créer un environnement d'équipe cohésif.

La sécurité doit être une priorité absolue pour tous les membres de l'organisation, le CISO étant visible et transparent et déployant des efforts à tous les niveaux pour assurer la sécurité de nos données. Je veux dire, qui voudrait entendre la même vieille chanson en boucle ? Il est temps de commencer sérieusement à éliminer définitivement les vieux bugs.