Pourquoi les injections SQL sont les cafards du monde de la sécurité des applications (et comment les RSSI peuvent les éradiquer une fois pour toutes)

Selon une théorie bien connue, les blattes peuvent survivre à pratiquement tout, même à une explosion nucléaire. Bien que cette théorie ne soit vraie que dans une certaine mesure, leur composition corporelle simple les rend extrêmement résistants pour leur taille et difficiles à éradiquer dans la plupart des conditions.

Je me suis dit... si les cafards avaient un équivalent dans le monde numérique, il faudrait qu'il s'agisse de vulnérabilités d'injection SQL (SQLi) dans le code. Cette vulnérabilité est connue depuis plus de vingt ans, mais les organisations en sont victimes à maintes reprises. La très répandue, attaque coûteuse contre Target était le résultat d'une injection SQL, tout comme une instance de piratage des élections dans l'Illinois, où 200 000 dossiers d'électeurs ont été révélés, ce qui a incité le FBI à recommander à tous les administrateurs informatiques de renforcer rapidement leurs pratiques de sécurité.

D'Imperva Rapport sur la Hacker Intelligence Initiative a révélé qu'entre 2005 et 2011, des attaques SQLi ont été utilisées dans 83 % des violations de données signalées. Aujourd'hui, les vulnérabilités liées à l'injection restent la principale menace dans Top 10 de l'OWASP. Ils sont relativement simples, mais ils ne mourront tout simplement pas.

Il semble ridicule que cette même vulnérabilité apparaisse toujours dans un nombre important d'analyses de sécurité des applications. Nous savons comment il fonctionne et comment l'arrêter. Comment est-ce possible ? La vérité est que la sécurité de nos logiciels peut encore être améliorée.

de Veracode Rapport sur l'état de la sécurité logicielle - basé sur 400 000 scans d'applications en 2017 » a révélé une statistique alarmante : seulement 30 % des applications ont satisfait à la politique du Top 10 de l'OWASP. Ce thème a été récurrent au cours des cinq dernières années, des injections SQL étant apparues dans près d'une application récemment 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 responsables de la sécurité informatique semblent avoir du mal à recruter suffisamment de talents en matière de sécurité. En règle générale, le ratio entre les spécialistes de la sécurité des applications et les développeurs est insuffisant pour 100.

Pourquoi la sécurité logicielle est-elle en mode survie ?

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

Je discute constamment avec des professionnels de la sécurité, des RSSI et des PDG et, pour l'anecdote, j'ai découvert que de nombreuses entreprises sont tellement frustrées par le nombre de vulnérabilités détectées qui ne peuvent être atténuées (en plus du fléau connu sous le nom de faux positifs), qu'elles arrêtent complètement de les rechercher, croisent les doigts et espèrent que tout ira pour le mieux.

Pourquoi les professionnels de l'AppSec laissent-ils cela se produire ?

Ne vous y trompez pas : les utilisateurs d'AppSec sont terriblement conscients des problèmes de code. Après tout, c'est l'une de leurs compétences de base qui fait d'eux une ressource d'équipe si précieuse. Cependant, ils sont souvent entravés par plusieurs facteurs.

Par exemple, un responsable AppSec détectera un problème et demandera au développeur : « Pouvez-vous 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 sollicité pour respecter les stricts sprints de fourniture de fonctionnalités qu'il n'a tout simplement pas le temps de résoudre ces problèmes, ni les outils adéquats pour les aider. Les professionnels de la sécurité des applications eux-mêmes sont peut-être en mesure d'identifier les vulnérabilités, mais ils n'ont souvent pas les compétences et/ou l'accès nécessaires pour y remédier sur place.

Nous devons également réaliser que pour chaque problème, il faut trouver une solution, la mettre en œuvre, puis la tester. Même pour le moindre problème détecté dans le code, le temps qu'il faut pour le résoudre, sans parler des ressources requises, est immense. Plus de 700 vulnérabilités peuvent être introduites dans les logiciels, et il est tout simplement impossible pour une seule personne de pouvoir se défendre contre toutes ces vulnérabilités. C'est pour cette raison que la plupart des entreprises s'en tiennent uniquement au Top 10 de l'OWASP. Pendant ce temps, les développeurs continuent de créer des fonctionnalités et, à leur tour, 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 le succès du codage sécurisé. Aucune réglementation n'oblige les entreprises à s'assurer que les développeurs possèdent les compétences adéquates en matière de sécurité, et la triste réalité est que la plupart des universités et des stages ne préparent pas non plus les développeurs débutants à coder en toute sécurité.

Lorsqu'une personne souhaite piloter un avion, il existe un processus très rigoureux qui garantit une formation, une expérience pratique, des contrôles médicaux, des connaissances en matière de sécurité et des examens avant de pouvoir voler. Personne n'oserait imaginer qu'il serait lâché dans le ciel sans cette préparation approfondie et cette validation des compétences, mais c'est ce qui se passe au quotidien avec l'écriture de code.

Nous devons consacrer du temps à former les développeurs à l'écriture de code sécurisé. Cependant, dans le monde d'aujourd'hui, où le développement de logiciels est rapide 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 de conversation.

Un titre récent du Forum économique mondial a crié : « Il ne peut y avoir d'économie numérique sans sécurité », avec le contenu qui l'accompagne faisant valoir la nécessité de placer la sécurité au cœur de toute stratégie de transformation numérique. « La sécurité est ce qui protège les entreprises, leur permet d'innover et de créer de nouveaux produits et services. Au-delà d'un rôle défensif, la sécurité fournit aux entreprises un avantage stratégique en termes de croissance. »

L'amélioration des compétences et des résultats en matière de codage sécurisé ajoutera une puissante couche de cyberprotection aux organisations, les aidant à créer un code plus efficace et plus rapide. Les développeurs n'ont pas besoin de devenir des experts en sécurité, mais ils doivent être habilités de manière positive et pratique pour être la première ligne de défense contre les cyberattaques. Les développeurs peuvent devenir les prochains héros de la sécurité et de l'innovation. Ce sont des personnes très intelligentes, elles savent résoudre les problèmes de manière créative et souhaitent généralement développer leurs compétences. Tirez parti de leurs points forts grâce à la formation spécialisée qu'ils méritent et engagez-vous à respecter des normes de sécurité logicielle plus strictes. Lisez notre livre blanc pour en savoir plus.

Lorsqu'une personne souhaite piloter un avion, il existe un processus très rigoureux qui garantit une formation, une expérience pratique, des contrôles médicaux, des connaissances en matière de sécurité et des examens avant de pouvoir voler. Personne n'oserait imaginer qu'il serait lâché dans le ciel sans cette préparation approfondie et cette validation des compétences, mais c'est ce qui se passe au quotidien avec l'écriture de code.