Pourquoi les injections SQL sont les cafards du monde de l'AppSec (et comment les RSSI peuvent les éradiquer une fois pour toutes)

Une théorie bien connue veut que les cafards puissent survivre à pratiquement tout, même à une explosion nucléaire. Si cette théorie n'est vraie que jusqu'à un certain point, leur constitution simple les rend extrêmement résistants pour leur taille et difficiles à éradiquer dans la plupart des conditions.

J'y réfléchissais... si les cafards avaient un équivalent dans le monde numérique, ce serait sans aucun doute les vulnérabilités par injection SQL (SQLi). Il s'agit d'une faille connue depuis plus de vingt ans, et pourtant, les organisations continuent d'en être victimes encore et encore. L'attaque généralisée et coûteuse contre Target était le résultat d'une injection SQL, tout comme un cas de piratage électoral dans l'Illinois, où 200 000 dossiers d'électeurs ont été exposés, incitant le FBI à recommander à tous les administrateurs informatiques d'agir rapidement pour renforcer leurs pratiques de sécurité.

Le rapport Hacker Intelligence Initiative d'Imperva a révélé qu'entre 2005 et 2011, les attaques par injection SQL ont été utilisées dans 83 % de toutes les violations de données signalées. Aujourd'hui, les vulnérabilités par injection restent la menace numéro un du classement OWASP Top 10. Elles sont relativement simples, mais elles refusent de disparaître.

Il semble absurde que cette même vulnérabilité apparaisse encore dans un nombre important d'analyses de sécurité des applications. Nous savons comment elle fonctionne et nous savons comment l'arrêter. Comment est-ce possible ? La vérité est que notre sécurité logicielle a une immense marge de progression.

Le rapport State of Software Security de Veracode — basé sur 400 000 analyses d'applications en 2017 — a révélé une statistique alarmante : seulement 30 % des applications respectaient la politique OWASP Top 10. C'est une tendance constante depuis cinq ans, les injections SQL apparaissant dans près d'une application scannée sur trois. C'est la preuve d'un problème endémique ; nous ne tirons pas les leçons de nos erreurs, et les RSSI semblent mener un combat difficile pour réussir à recruter suffisamment de talents en sécurité. En général, le ratio de spécialistes en sécurité applicative par rapport aux développeurs est d'un niveau inadéquat de 1 pour 100.

Pourquoi la sécurité logicielle est-elle sous assistance respiratoire ?

Ce n'est un secret pour personne que les talents spécialisés en sécurité sont rares, mais nous devons également prêter attention au fait que les développeurs ne corrigent pas les problèmes au fur et à mesure qu'ils surviennent, et qu'ils sont manifestement mal équipés pour éviter d'introduire des vulnérabilités dès le départ. Dans le même rapport de Veracode, il a été révélé qu'il existait des mesures d'atténuation documentées pour seulement 14,4 % de toutes les vulnérabilités de développement. En d'autres termes, la plupart des vulnérabilités ont été soumises sans mesure d'atténuation. Moins d'un tiers des vulnérabilités ont été corrigées dans les 90 premiers jours, et 42 % n'ont jamais été corrigées au cours de la période de développement.

Je parle constamment à des professionnels de la sécurité, des RSSI et des PDG, et j'ai pu constater que de nombreuses entreprises sont tellement frustrées par le nombre de vulnérabilités trouvées qui ne peuvent être atténuées (en plus du fléau des faux positifs) qu'elles finissent par arrêter complètement les analyses, croisant les doigts en espérant que tout se passe bien.

Pourquoi les professionnels de la sécurité applicative laissent-ils faire cela ?

Ne vous y trompez pas : les experts en sécurité applicative sont douloureusement conscients des problèmes dans le code. Après tout, c'est l'une de leurs compétences fondamentales qui fait d'eux une ressource si précieuse pour une équipe. Cependant, ils sont souvent entravés par plusieurs facteurs.

Par exemple, un responsable de la sécurité applicative trouvera un problème et demandera au développeur : « Peux-tu corriger le code ? ». La réponse à cette question importante varie d'une organisation à l'autre, mais en général, le développeur est tellement sous pression pour respecter des cycles de livraison de fonctionnalités stricts qu'il n'a tout simplement pas le temps de corriger ces problèmes, ni les outils adéquats pour l'aider. Les professionnels de la sécurité applicative peuvent être capables d'identifier les vulnérabilités, mais ils manquent souvent des compétences et/ou de l'accès nécessaires pour les corriger sur-le-champ.

Nous devons également réaliser que pour chaque problème, il existe un processus qui nécessite de trouver une solution, de la mettre en œuvre, puis de la tester. Pour le moindre problème détecté dans le code, le temps nécessaire à sa correction, sans parler des ressources requises, est immense. Il existe plus de 700 vulnérabilités pouvant être introduites dans un logiciel, et il est tout simplement impossible pour une seule personne de pouvoir toutes les contrer. C'est pour cette raison que la plupart des entreprises se contentent de suivre uniquement l'OWASP Top 10. Pendant ce temps, les développeurs continuent de créer des fonctionnalités et, par conséquent, continuent d'introduire des vulnérabilités dans le code qu'ils écrivent.

Quelle est la solution ?

Le fait est que nous ne donnons pas à nos développeurs les outils et la formation nécessaires pour favoriser un développement sécurisé. Il n'existe aucune réglementation obligeant les organisations à s'assurer que les développeurs possèdent des compétences en sécurité adéquates, et c'est une triste réalité que la plupart des universités et des stages ne préparent pas non plus les développeurs juniors à coder de manière sécurisée.

Lorsqu'une personne veut piloter un avion, il existe un processus très rigoureux qui garantit une formation, une expérience pratique, des examens médicaux, des connaissances en sécurité et des examens avant qu'elle ne soit autorisée à voler. Personne n'oserait imaginer qu'on puisse les laisser s'envoler sans cette préparation approfondie et cette validation des compétences, et pourtant, c'est ce qui se passe au quotidien avec l'écriture de code.

Nous devons prendre le temps d'éduquer les développeurs à l'écriture de code sécurisé. Cependant, dans le monde actuel, où le développement logiciel évolue rapidement et où les bons développeurs et professionnels de la sécurité sont rares, cela ne semble jamais être une priorité. Il est temps de changer la donne.

Un titre récent du Forum économique mondial clamait : « Il ne peut y avoir d'économie numérique sans sécurité », le contenu associé soulignant la nécessité de faire de la sécurité une partie intégrante de toute stratégie de transformation numérique. « La sécurité est ce qui protège les entreprises, leur permettant d'innover, de créer de nouveaux produits et services. Au-delà d'un rôle défensif, la sécurité offre aux entreprises un avantage stratégique de croissance. »

Améliorer les compétences et les résultats en matière de codage sécurisé ajoutera une couche de cyberprotection puissante pour les organisations, les aidant à créer un code meilleur et plus rapide. Les développeurs n'ont pas besoin de devenir des experts en sécurité, mais ils doivent être encouragés de manière positive et pratique à constituer la première ligne de défense contre les cyberattaques. Les développeurs peuvent être les prochains héros de la sécurité et de l'innovation. Ce sont des personnes très intelligentes, des résolveurs de problèmes créatifs, et généralement désireux de développer leurs compétences. Misez sur leurs points forts avec la formation spécialisée qu'ils méritent et engagez-vous à respecter une norme de sécurité logicielle plus élevée. Lisez notre livre blanc pour en savoir plus.

Lorsqu'une personne souhaite piloter un avion, un processus très rigoureux garantit une formation, une expérience pratique, des examens médicaux, des connaissances en matière de sécurité et des examens avant qu'elle ne puisse voler. Personne n'oserait imaginer qu'on puisse la laisser s'envoler sans cette préparation approfondie et cette validation des compétences, et pourtant, c'est ce qui se passe au quotidien avec l'écriture de code.