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

Cet article a été initialement publié sur. Informations sur la sécurité, et repris par plusieurs autres publications. Il a été mis à jour ici à des fins de syndication.

À la fin de l'année dernière, la remarquable communauté MITRE a publié une liste des 25 erreurs logicielles les plus dangereuses qui ont eu un impact mondial en 2019. Cette liste n'est pas basée sur des opinions, mais sur les résultats d'une analyse multidimensionnelle utilisant les travaux d'organisations telles que le NIST et le Common Vulnerabilities and Exposures (CVE). Le NISTa publié des données sur les vulnérabilités et les expositions courantes (CVE). Afin d'identifier les failles « majeures », celles-ci sont notées en fonction de leur gravité, de leur exploitabilité et de leur prévalence dans les logiciels actuels. Il ne s'agit pas d'une liste susceptible de susciter des éloges, cela ne fait aucun doute.

Cependant, contrairement à la plupart des résumés annuels, de nombreux participants figurant sur cette liste ont déjà été mentionnés précédemment. Si ce classement était le Billboard Hot 100, il serait similaire àcelui de Britney Spears.Baby One More Time et BackstreetBoys apparaissent chaque année depuis leur sortie initiale.Pourquoi ai-je sélectionné ces chansons ? Eh bien, j'ai environ vingt ans (cela semble-t-il déjà lointain ?) et, bien qu'elles aient été découvertes il y a plusieurs décennies, elles sont très similaires aux erreurs logicielles dangereuses qui continuent de nous affecter en 2020.

Pourquoi les anciens bugs restent-ils dangereux ? Comment les corriger ?

Actuellement, le sixième élément de la liste MITRE est mieux connu sous le nom de CWE-89SQLInjection (SQLi). La vulnérabilité SQLi a été découverte pour la première fois en 1998, à une époque où de nombreuses personnes posaient leurs questions les plus importantes à Zibs plutôt qu'à Google.Bien que des correctifs aient été rapidement mis à disposition, cette méthode reste l'une des techniques de piratage les plus utilisées en 2019. rapport sur l'état de l'Internet , SQLi était responsable de deux tiers des attaques. Toutes les attaques contre les applications web

En termes de complexité, l'injection SQL est loin d'être une exploitation de niveau génial. Il s'agit d'une solution simple pour les développeurs web, et nous devons sans hésiter apprendre comment empêcher cette vulnérabilité d'exposer des données précieuses aux attaquants... Le problème est qu'aujourd'hui encore, la sécurité n'est pas une priorité pour de nombreux développeurs. Cela était peut-être plus facile il y a 20 ans, mais avec la quantité considérable de logiciels créés aujourd'hui et à l'avenir, cela ne peut plus être considéré comme normal.

La plupart des développeurs travaillent sur des systèmes défaillants.

Il est très facile de rester assis et de critiquer les développeurs qui fournissent un code « incorrect ». En réalité, leurs priorités diffèrent considérablement de celles de l'équipe de sécurité. En général, on demande aux équipes de développement de créer des logiciels esthétiques et fonctionnels le plus rapidement possible. En raison de la demande sociale incessante en matière de logiciels, les équipes de développement sont déjà surchargées et la sécurité n'est pas une priorité. N'est-ce pas là la raison d'être des experts en sécurité des applications ? Les ingénieurs logiciels sont habitués à entretenir une relation quelque peu distante avec la sécurité. Ils ne sont sollicités que lorsque des problèmes surviennent, ce qui peut retarder leur travail déjà chargé.

En revanche, les experts en sécurité des applications sont épuisés de devoir corriger des erreurs vieilles de plusieurs décennies qui apparaissent systématiquement lors de chaque analyse et révision manuelle du code. Ces experts sont coûteux et rares, et il est préférable d'investir leur temps dans la correction de failles de sécurité complexes plutôt que dans l'élimination répétitive de bogues bien connus.

Ces équipes ont une culture implicite de transfert de responsabilité, mais elles partagent (ou devraient partager) le même objectif : la sécurité des logiciels. Les développeurs travaillent dans un environnement où ils ont peu de chances de réussir en matière de codage sécurisé. Les meilleures pratiques en matière de sécurité sont rarement enseignées dans l'enseignement supérieur, et la formation pratique est souvent trop rare ou inefficace. Il y a un manque flagrant de sensibilisation à la sécurité et de formation approfondie dans ce domaine. Il en résulte des coûts astronomiques pour corriger les anciens bogues du code validé et la menace imminente d'une atteinte à la réputation due à une violation des données.

Facteur humain, ou « Pourquoi tous ces outils ne parviennent-ils pas à sécuriser davantage les données ? »

Un autre problème récurrent est que, plutôt que de se concentrer sur la formation, une quantité considérable d'outils de sécurité est déployée pour détecter les problèmes avant la sortie des logiciels. Les outils d'inspection et de protection des applications en réseau (Fast/Dust/Raz/Toast) peuvent certes contribuer à la création de logiciels de sécurité, mais ils présentent leurs propres défis. Le fait de s'appuyer entièrement sur ces solutions ne garantit pas la sécurité. Les raisons sont les suivantes :

• Il n'existe pas d'outil unique capable d'examiner toutes les vulnérabilités dans tous les cas d'utilisation de tous les frameworks.
• En particulier, lorsque les analyses statique et dynamique du code sont exécutées simultanément, la vitesse peut être réduite.
• Les faux positifs constituent toujours un problème. Dans de tels cas, la production est souvent interrompue et une vérification manuelle inutile du code est nécessaire pour identifier les avertissements.
• Ces outils suscitent des attentes quant à leur capacité à résoudre les problèmes, ce qui conduit à une perception erronée de la sécurité, notamment en reléguant la priorité accordée au codage sécurisé.

Ces outils permettront certainement de détecter les failles de sécurité pouvant être corrigées par des correctifs. Cependant, peuvent-ils tout détecter ? Il n'est pas possible de garantir un taux de réussite de 100 %, et il suffirait qu'une seule porte soit laissée ouverte pour qu'un attaquant puisse s'introduire et causer des dommages considérables.

Heureusement, de nombreuses organisations reconnaissent l'importance du facteur humain. Vulnérabilité des logiciels. La plupart des développeurs n'ont pas reçu une formation suffisante en matière de codage sécurisé et ont une faible conscience globale de la sécurité. Cependant, ils se trouvent au début du cycle de vie du développement logiciel et sont les mieux placés pour empêcher les vulnérabilités de s'infiltrer dans le code validé. En codant de manière sécurisée dès le départ, ils peuvent constituer la première ligne de défense contre les cyberattaques destructrices qui causent des milliards de dollars de pertes chaque année.

Les développeurs doivent avoir la possibilité de réussir grâce à une formation leur permettant de maîtriser leur langage, d'acquérir des compétences pertinentes pour leur poste et de s'intéresser activement à la sécurité. Un code sans bug doit être une source de fierté. Tout comme la création d'une fonctionnalité remarquable peut susciter le respect de ses collègues.

Les programmes de sécurité les plus récents doivent constituer une priorité pour les entreprises.

L'équipe de développement ne peut pas utiliser Bootstrap pour promouvoir une culture de sécurité positive dans l'ensemble de l'entreprise. Pour intégrer la sécurité dès le début du processus de développement logiciel, il est nécessaire de disposer des outils, des connaissances et du soutien appropriés.

Si la liste du MITRE contient encore un nombre excessif de failles de sécurité anciennes, il est évident que les méthodes de formation précédentes ne sont pas efficaces. Par conséquent, il est recommandé d'essayer de nouvelles approches. Veuillez envisager les solutions de formation suivantes.

• Vous pouvez l'essayer par vous-même. Les développeurs préfèrent « apprendre en essayant par eux-mêmes » plutôt que de regarder des explications dans des vidéos.
• Pertinence : Si vous utilisez Java quotidiennement, il est préférable de ne pas vous former à C#.
• L'apprentissage intéressant et simple est facile à comprendre et permet aux développeurs de continuer à progresser en s'appuyant sur leurs connaissances antérieures.
• Mesurable. Veuillez ne pas simplement cocher la case et passer à autre chose. Veuillez vérifier l'efficacité de la formation et établir un plan d'amélioration.
• C'est intéressant. En plus de favoriser une culture de sécurité positive, veuillez examiner les moyens de renforcer la sensibilisation à la sécurité et de créer ainsi un environnement d'équipe cohérent.

La sécurité doit être une priorité absolue pour tous les membres de l'organisation, et le RSSI doit mener des efforts visibles et transparents à tous les niveaux pour renforcer la sécurité des données. En effet, qui souhaiterait entendre la même vieille chanson en boucle ? Il est temps de réfléchir sérieusement à la suppression définitive des anciens bugs.