Pourquoi nous devons soutenir, et non punir, les esprits curieux en cybersécurité

Les récentes révélations du jeune chercheur en sécurité Bill Demirkapi, exposant des vulnérabilités majeures dans les logiciels utilisés par son école, m'ont rappelé quelques souvenirs. Je me revois, enfant curieux, soulevant le capot des logiciels pour jeter un œil à l'intérieur et comprendre comment tout cela fonctionnait — et surtout, si je pouvais les faire planter. Depuis des décennies, les ingénieurs logiciels cherchent à améliorer et à renforcer continuellement leurs produits, et la communauté de la sécurité (bien que parfois un peu impertinente dans son approche) joue un rôle crucial dans la découverte de failles et de désastres potentiels, idéalement avant qu'une personne malveillante ne le fasse.

Cependant, le problème ici est qu'en réponse à ses découvertes, il a écopé d'une courte suspension scolaire. Et cela n'est arrivé qu'après qu'il ait épuisé toutes les pistes pour contacter l'entreprise (Follett Corporation) en privé, finissant par opter pour une approche plus publique afin de se faire identifier et de prouver sa capacité à pénétrer leur système. Ses tentatives répétées pour avertir éthiquement Follett Corporation sont restées sans réponse, tandis que le logiciel restait vulnérable et que des montagnes de données d'étudiants étaient exposées assez facilement, une grande partie n'étant même pas chiffrée.

Il a également traqué des bugs dans le logiciel d'une autre entreprise : Blackboard. Bien que les données de Blackboard aient été au moins chiffrées, des attaquants potentiels auraient pu s'y introduire et dérober des millions d'enregistrements supplémentaires. Ce logiciel, tout comme celui de Follett, était utilisé par son école.

Le récit du « hacker malveillant » est problématique.

Demirkapi a présenté ses conclusions lors de la DEF CON de cette année, les détails les plus espiègles de ses exploits ayant suscité les applaudissements de la foule. À juste titre, d'ailleurs — bien qu'il ait été initialement mal vu et confronté à de nombreux obstacles pour faire reconnaître ses découvertes, Follett Corporation aurait été reconnaissante de ses efforts et a suivi ses conseils, rendant finalement son logiciel plus sûr et évitant la crise de devenir une statistique de plus dans les fuites de données. Il rejoindra également le Rochester Institute of Technology après avoir terminé le lycée, il est donc clair qu'il est sur la bonne voie pour devenir un spécialiste de la sécurité très demandé.

En tant qu'expert en sécurité, il m'est difficile de ne pas contester la manière dont cette situation a été gérée. Bien que tout soit bien qui finit bien dans ce cas, il a d'abord été traité comme un « script kiddie » agaçant qui mettait son nez là où il ne fallait pas. Une recherche Google sur l'incident montre des articles qui le qualifient de « hacker » (dans l'esprit du profane en sécurité, cela le positionne comme le méchant), alors qu'en fait, son approche (et celle de beaucoup d'autres) est ce qui aide à protéger nos données.

Nous avons besoin de personnes curieuses, intelligentes et axées sur la sécurité pour regarder sous le capot, et nous avons besoin que cela arrive beaucoup plus souvent. En juillet, plus de quatre milliards d'enregistrements ont été exposés lors de fuites de données malveillantes cette année seulement. Vous pouvez potentiellement ajouter cinquante millions à ce chiffre, grâce à la fuite d'août chez la marque de mode et de style de vie Poshmark.

Nous commettons les mêmes erreurs et, plus inquiétant encore, il s'agit souvent de vulnérabilités simples, à s'en mordre les doigts, qui continuent de nous faire trébucher.

Le cross-site scripting et l'injection SQL n'ont pas disparu.

Comme rapporté par WIRED, le logiciel Community Engagement de Blackboard et le Student Information System de Follett contenaient, selon Demirkapi, des bugs de sécurité courants comme le cross-site scripting (XSS) et l'injection SQL, deux problèmes qui sont sur toutes les lèvres des spécialistes de la sécurité depuis les années 1990. Nous subissons leur existence depuis très longtemps, et tout comme les t-shirts Hypercolor et les disquettes, ils devraient être un lointain souvenir à présent.

Mais ce n'est pas le cas, et il est clair qu'un nombre insuffisant de développeurs fait preuve d'une sensibilisation adéquate à la sécurité pour empêcher leur introduction dans le code. Les outils d'analyse et les revues de code manuelles ne peuvent pas tout faire, et il existe des problèmes de sécurité bien plus complexes que le XSS et l'injection SQL, pour lesquels ces mesures coûteuses et chronophages seraient mieux utilisées.

Des personnes comme Bill Demirkapi devraient inspirer les développeurs à créer un code de meilleure qualité ; à seulement 17 ans, il a pénétré deux systèmes à fort trafic via des vecteurs de menace qui auraient dû être détectés et corrigés avant même que le code ne soit validé.

La ludification : la clé de l'engagement ?

J'ai beaucoup écrit sur les raisons pour lesquelles les développeurs restent largement désengagés vis-à-vis de la sécurité, et la réponse courte est que peu de choses sont faites, tant au niveau organisationnel qu'éducatif, pour favoriser des développeurs sensibilisés à la sécurité. Lorsque les entreprises prennent le temps de bâtir une culture de sécurité qui récompense et reconnaît l'engagement, notamment en mettant en œuvre une formation qui parle le langage des développeurs et les motive à persévérer, ces reliques de vulnérabilités agaçantes commencent à disparaître des logiciels que nous utilisons.

Demirkapi a manifestement un intérêt extrascolaire pour la sécurité et a pris le temps d'apprendre à faire de l'ingénierie inverse sur des logiciels malveillants, à repérer des failles et, eh bien, à casser des choses qui ne semblent pas cassées de l'extérieur. Cependant, en s'adressant à VICE (et via ses diapositives DEF CON), il a fait une déclaration intéressante sur son autodidactisme... il l'a ludifié :

« Avec pour objectif de trouver quelque chose dans le logiciel de mon école, c'était une façon amusante et "ludifiée" de m'enseigner une quantité importante de tests d'intrusion. Bien que j'aie commencé mes recherches avec l'intention d'en apprendre davantage, j'ai fini par découvrir que les choses étaient bien pires que ce à quoi je m'attendais », a-t-il déclaré.

Bien que tous les développeurs ne souhaitent pas se spécialiser dans la sécurité, chacun devrait avoir la possibilité de devenir sensibilisé à la sécurité, les bases servant presque de « permis de coder » au sein d'une organisation, en particulier pour ceux qui contrôlent des masses de nos données sensibles. Si les failles de sécurité les plus simples peuvent être corrigées par chaque développeur avant même d'être écrites, nous serons dans une position beaucoup plus sûre face à ceux qui cherchent à semer le chaos.

Curieux de découvrir la formation ludifiée ? Consultez notre série Coders Conquer Security sur le XSS et l'injection SQL.