Une version de cet article a été publiée dans Lecture sombre. Elle a été mise à jour et publiée ici.

‍

Dès les premiers bruits de couloir concernant les derniers outils d'IA qui bouleversent la culture, les développeurs et les curieux du codage les ont utilisés pour générer du code en appuyant sur un bouton. Les experts en sécurité ont rapidement souligné que, dans de nombreux cas, le code produit était de mauvaise qualité et vulnérable, et qu'entre les mains de personnes peu sensibilisées à la sécurité, il pouvait provoquer une avalanche d'applications et de développements web non sécurisés pour des consommateurs peu méfiants.

Et puis, il y a ceux qui ont suffisamment de connaissances en matière de sécurité pour les utiliser à des fins malveillantes. Pour chaque exploit époustouflant de l'IA, il semble qu'il y ait un contre-pied à l'utilisation de la même technologie à des fins malveillantes. L'hameçonnage, les fausses vidéos d'escroquerie, la création de logiciels malveillants, les manigances de script en général... ces activités perturbatrices sont réalisables beaucoup plus rapidement, avec des barrières à l'entrée plus faibles.

Il y a certainement beaucoup d'appâts à clics qui vantent cet outil comme étant révolutionnaire, ou du moins comme étant le meilleur lorsqu'il est comparé à des compétences humaines "moyennes". S'il semble inévitable que la technologie de l'IA de type LLM changera la façon dont nous abordons de nombreux aspects du travail - et pas seulement le développement de logiciels -, nous devons prendre du recul et considérer les risques au-delà des gros titres. 

Et en tant que compagnon de codage, ses défauts sont peut-être son attribut le plus "humain".

Les mauvais schémas de codage dominent les solutions proposées.

Avec ChatGPT formé sur des décennies de code existant et de bases de connaissances, il n'est pas surprenant qu'en dépit de toutes ses merveilles et de son mystère, il souffre également des mêmes pièges communs auxquels les gens sont confrontés lorsqu'ils naviguent dans le code. Les mauvais modèles de codage sont monnaie courante, et il faut encore un pilote conscient de la sécurité pour générer des exemples de codage sûrs en posant les bonnes questions et en fournissant les bonnes techniques d'intervention. 

Même dans ce cas, rien ne garantit que les extraits de code fournis sont exacts et fonctionnels du point de vue de la sécurité ; la technologie est sujette à des hallucinations, allant jusqu'à inventer des bibliothèques inexistantes lorsqu'on lui demande d'effectuer certaines opérations JSON spécifiques, comme l'a découvert Mike Shema. Cela pourrait conduire à un "squattage de l'hallucination" par les acteurs de la menace, qui ne seraient que trop heureux de créer un logiciel malveillant déguisé en la bibliothèque fabriquée recommandée en toute confiance par ChatGPT.

En fin de compte, nous devons nous rendre à l'évidence : en général, nous n'avons pas attendu des développeurs qu'ils soient suffisamment sensibilisés à la sécurité, et nous ne les avons pas non plus, en tant qu'industrie, suffisamment préparés à écrire du code sécurisé par défaut. Cela sera évident dans l'énorme quantité de données de formation introduites dans ChatGPT, et nous pouvons nous attendre à des résultats similaires en matière de sécurité, au moins dans un premier temps. Les développeurs devraient être en mesure d'identifier les bogues de sécurité et de les corriger eux-mêmes ou de concevoir de meilleurs messages-guides pour obtenir un résultat plus robuste.

La première étude à grande échelle menée par des chercheurs de l'université de Stanford sur la manière dont les utilisateurs interagissent avec un assistant de codage IA pour résoudre diverses fonctions liées à la sécurité vient étayer cette idée, avec une conclusion :

"Nous avons observé que les participants qui avaient accès à l'assistant d'intelligence artificielle étaient plus susceptibles d'introduire des failles de sécurité pour la majorité des tâches de programmation, mais aussi plus susceptibles d'évaluer leurs réponses non sécurisées comme étant sécurisées par rapport à ceux de notre groupe de contrôle."

Cela témoigne d'un niveau de confiance par défaut dans les résultats des outils de codage de l'IA comme produisant un code qui est toujours intrinsèquement sûr, alors qu'en fait il ne l'est pas.

Entre cela et les inévitables menaces liées à l'IA qui imprégneront notre avenir, les développeurs doivent plus que jamais perfectionner leurs compétences en matière de sécurité et relever la barre de la qualité du code, quelle qu'en soit l'origine.

Le chemin qui mène au désastre d'une violation de données est pavé de bonnes intentions

Il n'est pas surprenant que les compagnons de codage de l'IA soient populaires, en particulier parce que les développeurs sont confrontés à des responsabilités croissantes, à des délais plus serrés et aux ambitions d'innovation d'une entreprise qui reposent sur leurs épaules. Cependant, même avec les meilleures intentions, un manque de sensibilisation à la sécurité lors de l'utilisation de l'IA pour le codage conduira inévitablement à des problèmes de sécurité flagrants. Tous les développeurs utilisant des outils d'IA/ML produiront davantage de code, dont le niveau de risque de sécurité dépendra de leur niveau de compétence. Les organisations doivent être parfaitement conscientes du fait que les personnes non formées généreront certainement du code plus rapidement, mais qu'elles augmenteront également la vitesse de la dette de sécurité technique.

Même notre test préliminaire (avril 2023) avec ChatGPT a révélé qu'il génère des erreurs très élémentaires qui pourraient avoir des conséquences dévastatrices. Lorsque nous lui avons demandé de créer une routine de connexion en PHP à l'aide d'une base de données MySQL, le code fonctionnel a été généré rapidement. Cependant, il a choisi par défaut de stocker les mots de passe en clair dans une base de données, de stocker les identifiants de connexion à la base de données dans le code et d'utiliser un modèle de codage qui pourrait entraîner une injection SQL (bien qu'il ait effectué un certain niveau de filtrage sur les paramètres d'entrée et qu'il ait recraché les erreurs de la base de données). Des erreurs de débutants à tout point de vue :
‍

‍
Des rappels à l'ordre ont permis de corriger les erreurs, mais il faut des connaissances approfondies en matière de sécurité pour rectifier le tir. L'utilisation généralisée et non contrôlée de ces outils revient à lâcher des développeurs débutants sur vos projets, et si ce code construit des infrastructures sensibles ou traite des données personnelles, nous sommes face à une bombe à retardement.

Bien sûr, tout comme les développeurs débutants augmentent sans aucun doute leurs compétences avec le temps, nous nous attendons à ce que les capacités de l'IA/ML s'améliorent. Dans un an, elle ne commettra peut-être pas des erreurs de sécurité aussi évidentes et aussi simples. Toutefois, cela aura pour effet d'augmenter considérablement les compétences en matière de sécurité nécessaires pour traquer les erreurs de sécurité plus graves, cachées et non triviales qu'elle risque encore de produire.

Nous restons mal préparés à trouver et à corriger les failles de sécurité, et l'IA creuse l'écart.

Bien que l'on parle beaucoup du "glissement à gauche" depuis de nombreuses années, il n'en reste pas moins que, pour la plupart des organisations, la cohorte des développeurs manque cruellement de connaissances pratiques en matière de sécurité, et nous devons redoubler d'efforts pour leur fournir les outils et la formation adéquats afin de les aider à progresser.

Dans l'état actuel des choses, nous ne sommes pas préparés aux bogues de sécurité que nous avons l'habitude de rencontrer, sans parler des nouveaux problèmes liés à l'IA, tels que l'injection rapide et le squat des hallucinations, qui représentent des vecteurs d'attaque entièrement nouveaux et qui sont prêts à prendre leur essor comme une traînée de poudre. Les outils de codage de l'IA représentent l'avenir de l'arsenal de codage d'un développeur, mais c'est maintenant qu'il faut apprendre à manier ces armes de productivité en toute sécurité.

‍

Il est temps d'appliquer les principes agiles à la formation au code sécurisé

L'approche traditionnelle de la formation au code sécurisé dans la plupart des organisations la traite comme un exercice ponctuel avec un début et une fin discrets. À l'ère du numérique, les entreprises évoluent de plus en plus vite et cette approche ne suffit plus. Les organisations de toutes sortes doivent adopter une stratégie d'apprentissage continu intégrée au travail quotidien des développeurs. L'embauche de nouvelles compétences en matière de sécurité est une solution, mais ces talents sont rares et l'approche n'est pas évolutive. Tout comme les pratiques agiles ont dépassé l'approche en cascade dans le développement de logiciels, l'agile révolutionne maintenant la formation des développeurs en matière de sécurité. L'avantage de l'approche agile dans le domaine des logiciels était de diviser le travail en petits morceaux, en superposant un sprint sur le suivant pour garantir une livraison réussie à grande vitesse dans un cycle continu et itératif. De la même manière, l'apprentissage agile pour le code sécurisé est divisé en petits morceaux consommables, progressivement superposés et étroitement intégrés dans le flux de travail du développeur de manière itérative. Avec la méthode agile, les développeurs apprennent plus efficacement, intériorisent plus rapidement les compétences en matière de sécurité et écrivent un code plus sûr presque immédiatement.  

Formation traditionnelle à la sécurité contre une formation Agile Learning Platform pour un code sécurisé

L'apprentissage agile est un ensemble de valeurs et de principes qui encadrent la manière dont les gens intériorisent les connaissances plus rapidement et plus efficacement. Dans son Manifeste de l'apprentissage agile (représenté dans la figure 1 ci-dessous), Gartner définit quatre valeurs et huit principes.

Les quatre valeurs représentent un nouvel état d'esprit sur la manière d'envisager la formation des employés. L'apprentissage en tant que partie intégrante du travail valorise les résultats de l'entreprise, l'état d'esprit de croissance, la formation intégrée en temps réel et l'enrichissement de la communauté. Ces valeurs servent d'étoile polaire aux initiatives d'apprentissage et de cadre aux huit principes que nous décrivons brièvement ici.

1. Apprendre pour gagner : Lier les objectifs financiers et les besoins en compétences de l'entreprise à l'évolution des compétences du développeur. 
2. Multiplicateur de motivation : L'accès à une plateforme efficace de développement des compétences en matière de sécurité, que les développeurs peuvent appliquer à leur carrière pour progresser, les motive à en apprendre davantage.
3. Des micro-coupures juste à temps : De petits morceaux de contenu d'apprentissage d'une durée de 2 à 25 minutes, apparaissant au moment opportun, donnent un contexte, aidant les développeurs à acquérir des compétences pertinentes et utilisables.
4. Des parcours dynamiques : Le contenu relatif à la sécurité peut être présenté sous différents formats et les développeurs peuvent utiliser le mode qui convient le mieux à leur style d'apprentissage.
5. Une mise en place progressive : La maîtrise des concepts fondamentaux du code sécurisé est suivie de connaissances et de pratiques plus avancées.
6. Flux de livraison de la valeur : Les concepts de code sécurisé sont intégrés dans les outils et les espaces que les développeurs utilisent déjà, de sorte qu'ils n'ont pas besoin de quitter leur travail pour accéder à la formation.
7. Axé sur les données, basé sur l'IA : La technologie adapte dynamiquement les leçons et personnalise l'apprentissage pour maintenir les développeurs sur la bonne voie, en leur offrant une expérience personnalisée qu'ils ne pourraient jamais obtenir dans une salle de classe. 
8. Amplification sociale : L'instauration d'une culture d'apprentissage où les compétences en matière de codage sécurisé sont célébrées et où les développeurs participent à une compétition amicale ainsi qu'à un partage des connaissances a des effets bénéfiques sur l'ensemble de l'entreprise.

Présentation de la méthode agile learning platform pour un code sécurisé 

Au cours de la dernière décennie, Secure Code Warrior a intégré les principes agiles dans la conception de son site learning platform. Nous avons brisé le moule de la formation traditionnelle à la sécurité avec une expérience d'apprentissage flexible et axée sur les développeurs qui a apporté à nos clients une valeur commerciale de 2 à 3 fois supérieure dans plusieurs domaines, allant de la réduction des risques et des coûts à l'augmentation de la productivité des développeurs. Mais qu'est-ce qui définit une formation agile learning platform? Comment un learning platform agile pour le code sécurisé permet-il aux développeurs d'internaliser rapidement de nouvelles compétences et de les mettre en œuvre immédiatement ? Qu'est-ce qui rend l'apprentissage agile du code sécurisé meilleur que la formation traditionnelle à la sécurité ? Dans ce premier article d'une série de blogs, nous verrons comment le SCW Agile Learning Platform illustre plusieurs valeurs et principes agiles.

Des parcours dynamiques et des micro-coupures en flux tendu intégrés dans le flux de livraison de la valeur. 

Un site agile learning platform pour le code sécurisé offre à l'apprenant différentes façons de consommer du contenu, de faire progresser ses connaissances et d'intérioriser de nouvelles compétences. Elle offre aux développeurs des voies dynamiques pour trouver ce qui leur convient le mieux dans de petits micro-éclats de contenu consommables juste à temps, au moment où ils en ont besoin. Les utilisateurs peuvent choisir la forme d'apprentissage qui leur convient le mieux sur notre plateforme. Ils se familiarisent avec les concepts de sécurité grâce à des vidéos, des lignes directrices et des guides qui sont présentés sous forme de microréactions. Ces fonctionnalités fournissent les concepts fondamentaux - le "quoi" et le "comment" d'une vulnérabilité spécifique. Comme ce contenu est fourni dans les outils de développement qu'ils utilisent tous les jours, comme Jira, les concepts s'intègrent mieux et ont plus de sens, de sorte qu'ils peuvent être internalisés.

La plateforme SCW illustre le principe agile de la stratification progressive. Après s'être familiarisés avec les concepts du code de sécurité, les développeurs peuvent passer à des modules interactifs pratiques tels que les défis, missionset des laboratoires de codage où ils mettent en pratique les concepts fondamentaux introduits précédemment. Ces modules s'adaptent à différents niveaux de compétences et styles d'apprentissage, donnant aux développeurs le choix de la méthode d'apprentissage - des parcours dynamiques. 

‍

Passez de la formation à l'apprentissage agile

Passer d'une approche de formation à la sécurité à une approche d'apprentissage agile pour un code sécurisé est un moyen efficace d'habiliter votre personnel de développement, de récupérer les heures de travail perdues par les développeurs et d'utiliser ce temps pour des projets plus productifs. Dans ce billet, nous avons passé en revue quelques-unes des capacités de la plateforme Secure Code Warrioret la manière dont elles illustrent les principes d'une stratégie d'apprentissage agile. Dans le prochain article, nous démontrerons le bien-fondé de l'apprentissage sécurisé du code et présenterons d'autres fonctionnalités de la plateforme inspirées de la méthode agile.

A propos de Secure Code Warrior

Secure Code Warrior donne à vos développeurs les compétences nécessaires pour écrire du code sécurisé. Notre site learning platform est la solution de codage sécurisé la plus efficace car il utilise des méthodes d'apprentissage agiles pour que les développeurs apprennent, appliquent et retiennent les principes de sécurité des logiciels. Plus de 600 entreprises font confiance à Secure Code Warrior pour mettre en œuvre des programmes de sécurité par apprentissage agile, fournir rapidement des logiciels sécurisés et créer une culture de la sécurité axée sur les développeurs. Vous souhaitez en savoir plus ? Demandez une démonstration.

Cet article a été publié à l'origine dans le cadre du Forbes Technology Council. Il a été mis à jour et publié ici.

‍

Selon vous, combien d'enregistrements de données ont été compromis en 2022 ? Vous seriez sur la bonne voie si vous deviniez environ un demi-milliard. D'après les données publiques sur les atteintes à la vie privée, environ 480 014 323 enregistrements ont été volés rien que l'année dernière, mais ce chiffre est probablement beaucoup plus élevé. Quoi qu'il en soit, il s'agit d'une statistique qui donne à réfléchir au citoyen moyen et qui est très préoccupante pour tout professionnel de la sécurité en entreprise.

Nous sommes arrivés à un point où la plupart des habitants des pays développés ont probablement vu au moins une partie de leurs données personnelles tomber entre les mains de criminels à la suite d'une cyberattaque réussie ; il est donc tout à fait naturel que les gouvernements du monde entier cherchent des solutions pour endiguer ce flux perturbateur d'activités criminelles en ligne. La dernière initiative en date émane de l'administration Biden et prend la forme d'une stratégie nationale de cybersécurité, que j'observe avec un vif intérêt. Cette stratégie comprend des directives sur l'un de mes sujets préférés en ce moment : la responsabilité en matière de sécurité.

Cette stratégie, publiée à la suite d'une présentation décisive de Jen Easterly, directrice de la cybersécurité et de la sécurité des infrastructures à la CISA, a, à juste titre, suscité des divisions au sein de la communauté de la sécurité. Cependant, je pense qu'elle représente la meilleure chance que nous ayons d'améliorer les normes logicielles dans tous les domaines et, enfin, d'inaugurer une nouvelle ère de développeurs compétents en matière de sécurité.

Les fournisseurs auraient toujours dû être tenus responsables des logiciels non sécurisés.

Cela fait des décennies qu'en matière de sécurité des logiciels, la responsabilité est une patate chaude avec laquelle aucune équipe ne cherche à jongler. Les cadres et les équipes ont tendance à ne pas être d'accord sur la responsabilité finale de la sécurité des logiciels. Un rapport de Venafi révèle que 97 % des cadres supérieurs de l'informatique reconnaissent que les processus de création de logiciels ne sont pas suffisamment sûrs, mais qu'il existe une divergence sur la responsabilité finale de la mise en œuvre des meilleures pratiques en matière de sécurité. 61 % des cadres ont déclaré que les équipes de sécurité informatique devraient assumer la responsabilité de la sécurité des logiciels, tandis que 31 % ont déclaré que c'était à l'équipe de développement d'assumer cette responsabilité. Et ce n'est qu'une partie de l'équation : la question des composants commerciaux open-source et tiers dans les logiciels est une expansion constante de la surface d'attaque. Même entre les équipes AppSec et de sécurité, il y a rarement un "propriétaire" évident malgré la nécessité d'une vigilance continue dans la mise à jour, la surveillance et les tests.

Cette même enquête a également mis en lumière que - malgré un conflit interne sur qui devrait être responsable de la sécurité et de l'intégrité des logiciels - 94% des cadres estiment qu'il devrait y avoir des pénalités pour les fournisseurs de logiciels qui ne protègent pas leurs pipelines de construction contre les acteurs de la menace, et mettent les clients et les utilisateurs finaux en danger. 

Avec les récentes poursuites engagées contre le RSSI d'Uber pour sa mauvaise gestion d'une cyberattaque dévastatrice en 2016, ainsi que les initiatives réglementaires telles que le GDPR, nous voyons peu à peu les enjeux s'élever pour les fournisseurs qui jouent avec le feu en privant la sécurité de sa priorité. Cependant, cela ne suffit tout simplement pas. Nous sommes en train de perdre la bataille contre les cybercriminels, et bien que la pilule soit difficile à avaler, ce sont les pratiques laxistes des éditeurs de logiciels qui leur offrent des opportunités illimitées de prospérer. 

La stratégie nationale de cybersécurité cherche à tracer une ligne dans le sable et à mettre fin au jeu des reproches circulaires en attribuant la pleine responsabilité des logiciels non sécurisés au vendeur.

Jetons un coup d'œil :

Objectif stratégique 3.3 - Déplacer la responsabilité des produits et services logiciels non sécurisés :

"Trop de fournisseurs "ignorent les meilleures pratiques en matière de développement sécurisé, livrent des produits dont les configurations par défaut ne sont pas sûres ou dont les vulnérabilités sont connues, et intègrent des logiciels tiers dont la provenance n'est pas vérifiée ou inconnue.

Nous devons commencer à faire porter la responsabilité sur les entités qui ne prennent pas de précautions raisonnables pour sécuriser leurs logiciels, tout en reconnaissant que même les programmes de sécurité logicielle les plus avancés ne peuvent pas prévenir toutes les vulnérabilités".

Cela a, à juste titre, froissé certaines personnes. Mais, comme pour d'autres moments décisifs dans l'élaboration de normes et de réglementations dans la plupart des secteurs, c'est la douleur à moyen terme qui garantit un meilleur résultat à long terme. En tant qu'éditeur de logiciels, il est logique que la responsabilité nous incombe en matière de sécurité. Il s'agit de notre pipeline de construction, de nos processus et de notre contrôle de la qualité, et si nous commettons une erreur, il est de notre responsabilité d'y remédier.

En outre, nous devrions être dans une situation où nous cherchons à créer des logiciels de la plus haute qualité possible, et le codage sécurisé doit faire partie des paramètres qui définissent un résultat réussi. Il s'agit là d'une tâche ardue dans un monde qui privilégie la rapidité à tout prix, mais il incombe aux responsables de la sécurité qui guident notre avenir de veiller à ce que tous les acteurs du processus de création de logiciels, et en particulier les développeurs, reçoivent une formation adéquate leur permettant d'appliquer les meilleures pratiques en matière de sécurité dans le cadre de leur rôle. 

Nous manquons encore d'indications sur les meilleures pratiques à long terme.

L'objectif stratégique 3.3 fait référence au cadre bien établi de développement de logiciels sécurisés du NIST comme base de ses meilleures pratiques générales, et il s'agit de lignes directrices complètes et globales. Elles précisent la nécessité de "veiller à ce que le personnel, les processus et la technologie de l'organisation soient prêts à assurer le développement de logiciels sécurisés au niveau de l'organisation", mais ne sont pas particulièrement prescriptives sur les facteurs que, par exemple, un responsable de la sensibilisation à la sécurité devrait connaître lorsqu'il choisit des solutions d'habilitation.

Pour que l'approche soit réellement transformatrice, les développeurs doivent être considérés comme faisant partie intégrante du programme de sécurité et se voir offrir toutes les possibilités d'améliorer leurs compétences et de partager la responsabilité de la détection et de l'éradication des vulnérabilités. Ils ne peuvent y parvenir de manière mesurable sans un apprentissage et des outils hyper pertinents et contextuels, ni si cela est considéré comme un exercice de conformité annuel au lieu d'un parcours de développement continu des compétences. 

Les développeurs sont une pièce importante du puzzle lorsqu'il s'agit de résoudre l'énigme de la sécurité, et une équipe de développeurs compétents en matière de sécurité est essentiellement l'ingrédient manquant dans la plupart des organisations. Ils permettent d'accélérer la sécurité, mais uniquement lorsque du temps et des ressources sont consacrés à cette tâche au sein de l'équipe. En attendant, toutes les lignes directrices générales sur les meilleures pratiques du monde ne parviendront pas à faire bouger l'aiguille.

Le long chemin vers le nirvana de la sécurité des logiciels.

L'administration Biden s'est engagée à financer la CISA à hauteur de 3 milliards de dollars, dans le but d'assurer une résilience rapide des infrastructures critiques. Si le financement et le soutien des plus hauts niveaux de gouvernement sont essentiels, pour que nous ayons une chance de contrecarrer les acteurs de la menace, il faudra un effort mondial pour réécrire l'histoire de la culture de la sécurité.

La route est longue, mais elle commence avec chaque éditeur de logiciels qui fait le premier pas courageux vers la responsabilisation en matière de sécurité au niveau de l'organisation.

Le 20 mars 2023, Spring Security Advisories a publié un billet de blog faisant référence à une vulnérabilité découverte en interne, CVE-2023-20860. Aucune information détaillée n'a été divulguée, si ce n'est qu'il s'agissait d'un problème de contrôle d'accès concernant l'utilisation de mvcMatchers. Les développeurs de Spring ont remédié au problème et une mise à jour de la version est conseillée.

Souhaitez-vous vivre une expérience de première main ? Essayez la mission ici.

La sécurité étant notre principale préoccupation chez Secure Code Warriornous avons décidé de nous pencher sur la vulnérabilité de mvcRequestMatchers et de comprendre où se situe le problème.

Spring fournit l'interface RequestMatcher pour déterminer si une requête correspond à un modèle de chemin. Jetez un coup d'œil à l'extrait de code ci-dessous dans lequel la méthode d'aide mvcMatchers est utilisée pour enregistrer les points de terminaison avec leurs exigences en matière d'authentification et d'autorisation. Par exemple, nous pouvons voir que seuls les utilisateurs ayant le rôle ADMIN peuvent accéder au point de terminaison /logs/audit . 

MvcMisMatchers?

Dans Spring, ** est un modèle qui permet de faire correspondre un nombre quelconque de répertoires et de sous-répertoires dans une URL. Par exemple, /bankaccount/** correspondrait à toutes les URL commençant par /bankaccount/, y compris les sous-répertoires tels que /bankaccount/dashboard/settings. 

Le motif * est un motif qui correspond à n'importe quelle URL et qui comporte exactement un niveau de sous-répertoire. Par exemple, /bankaccount/* correspondrait à bankaccount/dashboard.

Lors de la configuration des filtres avec *, Spring indique qu '"une erreur dans la correspondance des motifs entre Spring Security et Spr ing MVC" s'est produite, créant ainsi la vulnérabilité.

Essentiellement, en raison de l'absence de séparateur devant le double caractère générique, le chemin ne correspond pas à une demande entrante, car toutes les demandes entrantes sont précédées d'une barre oblique. Cela signifie que les règles de contrôle d'accès ne sont pas appliquées, ce qui permet à tout utilisateur non authentifié d'accéder aux ressources.

Jetons un coup d'œil au commit qui a corrigé le problème.

La modification la plus importante est l'ajout de la ligne 315, qui corrige le contournement des règles d'autorisation et d'authentification. Elle garantit que tout modèle de chemin soumis est précédé d'une barre oblique (/). 

404 correspondance non trouvée

Lors de l'envoi d'une requête web à /bankaccounts/view , la méthode match analyse et compare les motifs définis dans le filtre de sécurité avec le chemin d'accès demandé. L'analyseur transforme le motif donné en un arbre d'éléments de chemin.

L'analyseur lit le premier caractère en tant qu'élément SeparatorPathElement. Il continue ensuite à lire les caractères de la chaîne jusqu'au séparateur suivant, en créant un nouvel élément LiteralPathElement.

Où se situe le problème lorsque l'on utilise ** comme modèle ? 

Bien qu'il existe de nombreux types d'éléments de chemin, les plus intéressants sont les éléments WildcardPathElementet WildcardTheRestPathElement, avec leurs représentations respectives sous forme de chaînes de caractères : * et /**. 

Un WildcardPathElement correspond à zéro ou plusieurs caractères dans un seul segment de chemin, tandis qu'un WildcardTheRestPathElement correspond à zéro ou plusieurs segments de chemin seuls (y compris les séparateurs).

Cette dernière nous donne un indice sur ce qui ne va pas lorsque l'on soumet ** comme motif. Lors de l'analyse syntaxique, il recherche des motifs, mais ** ne commence pas par la barre oblique attendue. Ainsi, au lieu de devenir un WildcardTheRestPathElement, il devient deux WildcardPathElements consécutifs.

Ensuite, le motif analysé est utilisé pour établir une correspondance avec l'URL demandée. Les chemins doivent commencer par une barre oblique, mais les caractères génériques ne correspondent pas aux séparateurs.

Cela signifie qu'au lieu d'un RequestMatchResult, c'est un null qui est renvoyé. Par conséquent, les règles de contrôle d'accès placées sur ce comparateur ne seront pas appliquées à l'URL demandée.

Spring a résolu le problème en ajoutant une barre oblique. En d'autres termes, tout motif ** devient /**, ce qui signifie qu'il peut être analysé comme un WildcardTheRestPathElement, et qu'un RequestMatchResult sera renvoyé car le motif correspond désormais à l'URL demandée.

Vulnérabilité ou utilisation abusive de l'API ?

On peut se demander si cela doit être considéré comme une vulnérabilité, car le code fonctionne comme prévu. Le problème réside essentiellement dans le fait que la documentation de Spring ne mentionne pas explicitement que les chemins doivent commencer par un séparateur. Par conséquent, on pourrait considérer qu'il s'agit davantage d'un cas de mauvaise utilisation de l'API que d'un bogue ou d'une vulnérabilité.

Cette interview a été publiée à l'origine dans CyberNews.

‍

Malgré la prévalence des outils et des services de sécurité, les entreprises ont encore du mal à suivre l'évolution constante du paysage des menaces.

Cela peut être attribué au manque de sensibilisation et de formation à la sécurité parmi les développeurs, ce qui peut conduire à la publication de code risqué et à son exploitation par des acteurs malveillants. Si les mesures de sécurité telles que les logiciels antivirus ou les solutions d'analyse des vulnérabilités peuvent ajouter une couche de sécurité, notre invité d'aujourd'hui explique que tout commence par une équipe de développement axée sur la sécurité.

Pour discuter de la façon dont les développeurs peuvent être formés à l'identification et à l'atténuation des menaces de sécurité, l'équipe de CyberNews s'est entretenue avec Pieter Danhieux, PDG et cofondateur de Secure Code Warriorune société qui propose un site learning platform et une suite d'outils axés sur les développeurs qui aident les équipes de développement à identifier les vulnérabilités en matière de sécurité.

Comment s'est déroulé votre parcours ? Comment est née l'idée de Secure Code Warrior ?

Jeune intello, j'étais fasciné par l'idée de démonter la technologie pour découvrir ce qu'elle contenait et comment elle fonctionnait. Au grand soulagement de ma famille et de nos appareils communs, j'ai fini par adopter la même approche avec le matériel et les logiciels, en cherchant des moyens de les percer et de les briser. Une passion pour la sécurité est née et, pendant de nombreuses années, je me suis attaché à partager mes compétences en matière de "casse" avec des étudiants, des collègues et la communauté de la sécurité, en montrant comment trouver, utiliser et abuser des erreurs dans les logiciels. Plus tard, je me suis recentré sur le renforcement des compétences des défenseurs, en enseignant aux développeurs des modèles de codage sûrs et efficaces dans un environnement scolaire, et en les aidant à comprendre les vulnérabilités courantes et la manière de les éviter. J'ai également travaillé dans le domaine du conseil, où j'ai conseillé de grandes entreprises sur la manière dont elles pouvaient améliorer leurs programmes de sécurité, en particulier en ce qui concerne l'implication des développeurs. C'est à cette époque que j'ai rencontré l'équipe fondatrice de Secure Code Warrior. Ensemble, nous avons compris les problèmes auxquels les équipes de sécurité et de développement étaient confrontées lorsqu'il s'agissait de vulnérabilités au niveau du code, ainsi que les problèmes que posaient la plupart des solutions de formation destinées à améliorer les compétences des développeurs en matière de sécurité. Nous avons commencé à travailler sur notre vision d'un site learning platform qui pourrait être mis à l'échelle de l'entreprise, tout en restant amusant et engageant pour les développeurs. En fin de compte, nous voulions créer une suite d'outils adaptés à l'environnement de travail des développeurs, moins perturbants et les aidant à développer un état d'esprit axé sur la sécurité. Et nous nous sommes efforcés de rendre cette suite aussi flexible que possible en termes de langage et de contenu.

Pouvez-vous nous présenter ce que vous faites ? Quels sont les principaux défis que vous aidez à relever ?

En fin de compte, nous aidons les entreprises à accélérer le développement de leurs logiciels en éliminant les problèmes de sécurité et les retards souvent dus à l'utilisation de mauvais modèles de sécurité dans le code. Nous avons créé un site learning platform et une suite d'outils destinés aux développeurs qui aident les équipes de développement à naviguer dans les vulnérabilités de sécurité courantes, dont beaucoup existent depuis des décennies et continuent aujourd'hui d'exposer les entreprises à des risques cybernétiques. La raison pour laquelle elles persistent est que les développeurs n'ont pas la formation et les compétences nécessaires pour remédier à ces problèmes au niveau du code, et qu'ils les introduisent souvent en premier lieu par l'utilisation continue de modèles et de techniques de codage médiocres. On ne leur enseigne pas le codage sécurisé au niveau tertiaire, et la plupart des programmes de formation sur le lieu de travail sont inefficaces pour fournir un contenu pertinent pour leur travail quotidien, en plus d'être trop peu fréquents pour avoir un véritable impact sur la qualité du code et la sécurité au fil du temps. Nos solutions visent à fournir un développement des compétences attrayant et pertinent qui modifie les comportements de codage et les aide à mettre la sécurité au premier plan dans le monde réel. Nous nous intégrons de plus en plus aux environnements les plus familiers des développeurs, et l'accent que nous mettons sur l'apprentissage contextuel donne aux utilisateurs les meilleures chances de retenir les résultats clés de l'éducation. Nous nous efforçons également de le faire d'une manière qui aide les développeurs à voir la sécurité sous un jour positif et amusant qui récompense le succès et construit la communauté.

L'apprentissage du codage sécurisé pouvant sembler fastidieux à certains, comment faites-vous pour que votre formation soit à la fois efficace et divertissante ?

Notre produit phare, learning platform , a été conçu en tenant compte de l'engagement des développeurs. L'une des fonctions les plus populaires est le mode Tournament , qui permet aux participants de tester les connaissances acquises au cours de la formation par rapport à leurs pairs. Des points sont attribués pour chaque bonne réponse et un tableau de classement en direct est mis à jour tout au long de la session tournament . Nous avons organisé ces sessions lors d'événements communautaires et de conférences, et certains de nos clients ont mis en place des thèmes incroyablement complexes où tout le monde est venu déguisé. En outre, notre contenu en général est disponible dans plus de soixante cadres de programmation, en utilisant des extraits de code réels qu'ils verront dans leur travail quotidien. Il est tellement plus facile de rester engagé lorsque le contenu est hyper pertinent et aide à résoudre des problèmes réels, plutôt que de regarder des vidéos ou un examen de conformité annuel.

Quels sont, selon vous, les principaux défis auxquels les développeurs sont confrontés aujourd'hui ?

Je pense qu'il est important d'établir que les développeurs veulent bien faire, mais qu'ils n'ont pas été suffisamment sensibilisés à la sécurité au cours de leur formation ou de leur carrière, ce qui est à l'origine de nombreux problèmes qu'ils rencontrent du point de vue de la sécurité. Ils ont également tendance à considérer que la sécurité n'entre pas dans le champ de leurs responsabilités et, dans la grande majorité des organisations, leurs indicateurs clés de performance n'incluent rien qui soit lié aux résultats en matière de codage sécurisé. Cependant, les développeurs ont besoin d'un soutien et d'outils adéquats pour être à l'origine du changement que nous voulons voir, et le défi consiste à les habiliter efficacement, à leur donner le temps de se former et à investir dans ce perfectionnement aujourd'hui afin d'atteindre la sécurité à la vitesse grand V plus tard.

Comment les récents événements mondiaux ont-ils affecté votre domaine de travail ?

Alors que toutes les entreprises ont sans aucun doute ressenti les effets du climat mondial actuel sur leurs objectifs, leurs projections et leurs budgets, nous avons eu la chance de résister à la tempête jusqu'à présent. La cybersécurité est un élément non négociable pour la plupart des entreprises, et nous nous efforçons de continuer à participer à cette conversation avec nos clients et nos prospects.

Quelles sont les meilleures pratiques que les organisations devraient suivre lorsqu'elles développent des logiciels ou des applications ?

Chaque organisation a ses propres nuances, mais en général, les entreprises qui appliquent les meilleures pratiques de sécurité sont prêtes à sortir des sentiers battus et à essayer différentes approches. Elles n'oublient pas le pouvoir des personnes pour faire une différence positive dans les résultats en matière de sécurité. Cependant, face à la pénurie mondiale de compétences en matière de sécurité qui ne sera probablement pas comblée de sitôt, les développeurs qui s'intéressent à la sécurité peuvent contribuer à réduire les risques et à assurer la conformité du point de vue de la création de logiciels. Ils peuvent avoir un impact au stade le plus précoce et le moins coûteux possible du processus.

Outre les outils de codage sécurisés, quelles sont les autres mesures ou pratiques qui, selon vous, peuvent non seulement améliorer mais aussi sécuriser les opérations commerciales ?

Chaque entreprise devrait disposer d'une sorte de formation à la sécurité basée sur les rôles. Il existe une pléthore de menaces qui existent en dehors des exploits au niveau du code que les acteurs de la menace cherchent à exploiter, de sorte que chaque personne dans l'organisation doit avoir des bases régulières dans les principes de sécurité tels qu'ils s'appliquent à leur travail.En ce sens, tout le monde, du chef de bureau à l'équipe de comptabilité, devrait comprendre et embrasser le rôle qu'il joue dans l'action et la sensibilisation en matière de cybersécurité.

Compte tenu du climat économique actuel, les RSSI sont soumis à une forte pression pour assurer la sécurité des entreprises au moindre coût.

Dans ce contexte, les RSSI doivent faire preuve de créativité, d'autant plus que la législation en matière de cybersécurité devient de plus en plus exigeante et que, dans certains cas, les RSSI sont tenus personnellement responsables en cas de violation. Ajoutez à cela les licenciements et vous obtenez une situation où moins d'ingénieurs devront assumer plus de responsabilités tout en écrivant le même volume de logiciels. Les RSSI peuvent aider les entreprises à réussir en s'attaquant à l'un des principaux obstacles qui les ralentissent : la sécurité.

L'étape la moins coûteuse pour remédier aux vulnérabilités de sécurité au niveau du code et aux erreurs de configuration est de loin celle qui précède la livraison du logiciel, ce qui place naturellement le développeur dans une position privilégiée pour réduire ce risque. Cependant, ils ont besoin d'un soutien adapté pour y parvenir. La sécurité à grande vitesse est possible si l'on fournit à la cohorte d'ingénieurs des outils axés sur le développement, en tenant compte de leur flux de travail et de leur pile technologique actuels. Ils ont besoin d'être soutenus pour atteindre la précision en matière de sécurité à grande vitesse, et la meilleure façon d'y parvenir est de leur montrer comment utiliser des modèles de codage sécurisés et corriger les problèmes plus rapidement.

Pour le coût d'une formation complète des développeurs, vous pouvez essentiellement travailler à l'élimination des vulnérabilités à la source, ce qui permet d'économiser du temps et de l'argent plus tard dans le cycle de vie du développement logiciel (SDLC). Compte tenu de la fréquence des attaques à grande échelle et de la responsabilité accrue des RSSI, nous devons cesser d'accuser la pénurie de compétences en cybersécurité d'être à l'origine de notre retard. Donnez la priorité aux pratiques de sécurité défensives et renforcez le personnel qui se trouve déjà devant vous.

Que réserve l'avenir à Secure Code Warrior?

Nous voulons continuer à innover, en mettant l'accent sur les développeurs dans les solutions que nous mettons sur le marché. Nous nous efforçons de leur permettre d'assurer la sécurité sans compromettre la rapidité de livraison des fonctionnalités, ni leur santé mentale lorsqu'ils jonglent avec de multiples priorités.

Notre objectif est d'aider les organisations à révolutionner leur programme de sécurité défensive, et nous voulons que les développeurs en charge de la sécurité soient les héros de cette histoire. Surveillez cet espace.

Cet article a été publié pour la première fois dans SC Magazine. Il a été mis à jour et synthétisé ici.


Les RSSI se trouvent dans une situation de plus en plus délicate : Protéger plus d'actifs, livrer plus de code, réduire une plus grande surface d'attaque, et le faire avec des ressources financières qui diminuent rapidement. C'est un fait inéluctable que la cybersécurité est considérée comme un centre de coûts, et bien que le programme de sécurité d'une organisation soit ce qui s'oppose à ce qu'un acteur de la menace en fasse le titre désastreux de demain, les responsables de la sécurité doivent faire plus pour vendre et prouver la valeur commerciale globale du département, dans un langage qui a du sens pour l'organe exécutif.

Les RSSI de classe mondiale sont à la hauteur de la situation et dirigent des programmes de sécurité holistiques qui renforcent la confiance des clients et la réputation de la marque, et utilisent tous les outils à leur disposition pour créer une valeur indéniable. Cela commence par une approche stratégique et préventive des pièges courants en matière de sécurité et par l'abandon de la mentalité selon laquelle il n'y a jamais assez de temps, de ressources ou de personnel pour maintenir l'excellence en matière de sécurité.

Changez la discussion dans la salle du conseil d'administration.

Dans le climat économique actuel, peu d'entreprises et de départements échappent à l'examen minutieux de l'argent qu'ils dépensent, des embauches qu'ils effectuent et de leur impact stratégique sur les objectifs de l'entreprise. S'il peut sembler évident que l'entreprise moderne a besoin d'un programme de cybersécurité étendu, cela représente un coût important pour l'organisation, qu'il n'est pas facile de justifier en termes de retour sur investissement.

Les dirigeants et les membres du conseil d'administration devront comprendre clairement les résultats escomptés des initiatives de cybersécurité, en des termes qui n'ont pas de sens en dehors des chiffres d'une feuille de calcul. Ils auront différents niveaux de connaissances techniques et de compréhension, et les RSSI doivent s'efforcer de présenter leurs arguments avec des messages accessibles. Expliquez l'ampleur du programme, ce qu'il faut protéger et qui doit être habilité à le faire afin de fournir un exemple de premier ordre. Les attaques sont en hausse, mais les budgets ne suivent pas, et le bon combat commence par une campagne verbale pour justifier son bien-fondé.

On dit depuis longtemps que, quel que soit son secteur d'activité, toute entreprise est en train de devenir une entreprise technologique. L'approche numérique étant la norme dans la plupart des organisations, cela représente une énorme surface d'attaque qui nécessite la meilleure protection possible à ce moment-là. Les responsables de la sécurité portent de nombreuses casquettes, mais l'une d'entre elles est souvent négligée (jusqu'à ce qu'il soit trop tard) : ils sont essentiellement les gardiens de la confiance des clients. On ne saurait trop insister sur la valeur de cette proposition, qui est tout aussi vitale que les objectifs de vente et de marketing. 

Prouvez la valeur d'une approche préventive de la sécurité.

Les statistiques actuelles en matière de cybersécurité sont effrayantes, mais jouer sur la peur et l'alarmisme est généralement une tactique futile lorsqu'il s'agit d'obtenir un budget supplémentaire. Peu de membres de l'équipe dirigeante d'une entreprise soutiendraient que la cybersécurité n'est pas une priorité, mais ils sont beaucoup plus susceptibles d'être réceptifs aux augmentations de budget si une stratégie entreprenante est proposée, qui utilise les ressources existantes pour obtenir de meilleurs résultats. 

Selon une étude récente du Neustar International Security Council, seulement 50 % des entreprises estiment disposer d'un budget suffisant pour faire face aux problèmes de cybersécurité connus. Et comme les cyberattaques mondiales ont augmenté de 38 % entre 2021 et 2022, la route risque d'être encore plus difficile pour le RSSI moyen. Toutefois, les responsables de la sécurité de classe mondiale sont capables de surmonter ces difficultés et d'innover dans l'adversité.

Dans de nombreux scénarios, la prévention est plus facile et plus directe que la guérison, et la cybersécurité n'échappe pas à la règle. Un programme de sécurité holistique doit aller bien au-delà des mesures réactives, et comme la gestion des vulnérabilités figure parmi les trois principales préoccupations de nombreux RSSI, il est logique que les développeurs fassent partie intégrante de ce mouvement. Ils ont besoin d'une formation pratique pour s'attaquer de front aux bogues de sécurité les plus courants, ce qui les aide à éliminer ces problèmes à la source et à s'assurer qu'ils n'atteignent jamais le stade de la production. Nous sommes arrivés à un point où nous ne pouvons plus excuser un code de mauvaise qualité et peu sûr, et la formation continue des développeurs est de loin le remède le plus rentable et le plus efficace contre les vulnérabilités au niveau du code. 

Il est essentiel que les RSSI se battent pour conserver le budget existant, et détailler les avantages d'un renforcement des compétences en matière de sécurité basé sur les rôles, en particulier pour les développeurs, est une victoire plus rapide que d'ajouter la prochaine "solution miracle" à une pile de technologies de sécurité peu maniable.

La sécurité doit faire partie des fondamentaux de la marque.

La plupart des RSSI n'ont pas accédé à leur fonction pour exercer une passion pour le marketing, mais c'est un domaine sur lequel vous pourriez travailler, du moins lorsque vous présentez vos arguments à ceux qui tiennent les cordons de la bourse. 

L'impact d'un programme de cybersécurité sur la confiance des clients et la fidélité à la marque ne peut être surestimé, et une violation à grande échelle peut provoquer un exode de proportions bibliques. En revanche, en alignant vos pratiques de sécurité rigoureuses sur les valeurs fondamentales de votre marque, vous envoyez un message clair : la confidentialité et la protection des données ne sont pas seulement une priorité, c'est quelque chose sur lequel les clients peuvent compter. 

Il est essentiel que le RSSI moderne prenne le temps de souligner les avantages concurrentiels de la stratégie et de la politique de sécurité en ce qui concerne le sentiment positif et la confiance des clients ; la sécurité réactive seule n'aura pas le même impact, et une approche équilibrée qui se concentre sur la protection des actifs privilégiés avec toutes les ressources disponibles peut être l'ultime différentiateur. 

Il n'y a plus de place pour les excuses, mais il existe de nombreuses raisons convaincantes que les RSSI peuvent mettre en avant dans leur quête d'un financement adéquat pour une stratégie de sécurité véritablement transformatrice.

Cet article a été publié dans le SD Times. Il a été mis à jour et publié ici.

‍

La vérification des compétences fait partie de notre vie depuis la majeure partie de l'ère moderne, nous conférant une validité et nous ouvrant des portes qui ne seraient pas accessibles autrement. La conduite, par exemple, est un rite de passage important pour la plupart des gens, et nous sommes censés passer une série d'évaluations standardisées pour confirmer que nous pouvons avoir confiance en une machine de quatre mille livres, capable de rouler à plus de 160 km/h. Les erreurs, en particulier à grande vitesse, peuvent vous coûter ce privilège, voire un être humain. Les erreurs, surtout à grande vitesse, peuvent vous coûter ce privilège, voire une vie humaine.

Mais que se passerait-il si, pour certains, la conduite était plus qu'une commodité quotidienne et devenait une profession d'élite ? Une personne peut poursuivre son parcours de perfectionnement et devenir pilote de F1, où elle est autorisée à conduire des machines qui vont plus vite qu'aucun civil ne pourrait le faire de manière réaliste, sans qu'il y ait un risque énorme d'erreur à grande vitesse. 

À cette fin, il semble déconcertant que la plupart des développeurs qui travaillent sur le code qui alimente les infrastructures critiques, les automobiles, la technologie médicale et tout ce qui se trouve entre les deux, le fassent sans d'abord vérifier leurs prouesses en matière de sécurité. D'autre part, pourquoi les développeurs compétents en matière de sécurité, qui ont prouvé à maintes reprises qu'ils savaient comment construire des choses sûres, doivent-ils faire la queue avec tous les autres dans les pipelines de développement toujours plus lents à cause de toutes les barrières de sécurité ? L'industrie ne considère pas cela comme un oubli, c'est la norme. 

Des recherches approfondies nous ont appris que la plupart des développeurs n'accordent tout simplement pas la priorité à la sécurité dans leur code et qu'ils n'ont pas reçu la formation régulière nécessaire pour résoudre un grand nombre de bogues de sécurité courants. C'est en partie à cause d'eux que la sécurité à grande vitesse semble être une chimère et que de nombreux développeurs spécialisés dans la sécurité ont l'impression d'être coincés sur la voie lente de l'autoroute, derrière un groupe d'apprentis conducteurs. 

Malgré cela, le monde de la sécurité avance lentement et il existe une demande croissante de développeurs ayant des compétences vérifiées en matière de sécurité et capables d'être opérationnels. Le décret de l'administration Biden sur l'amélioration de la cybersécurité nationale demande spécifiquement l'évaluation des pratiques de sécurité des fournisseurs - et de leur cohorte de développeurs - pour tout fournisseur de la chaîne d'approvisionnement en logiciels du gouvernement américain. Il va de soi que l'importance accordée aux compétences des développeurs en matière de sécurité ne fera que croître dans la plupart des secteurs, mais avec peu d'offres en matière d'évaluations standard de l'industrie, comment les organisations peuvent-elles prouver que leur programme de sécurité développe des compétences vérifiables en matière de sécurité des développeurs d'une manière qui ne mettra pas la livraison à genoux, ou n'empêchera pas les développeurs conscients de la sécurité de déployer leurs ailes ?

Contrôle d'accès basé sur le mérite : Cela pourrait-il fonctionner ?

Les contrôles de sécurité à moindre privilège sont un pilier dans de nombreuses organisations, avec l'idée que chaque rôle se voit attribuer l'accès aux logiciels, aux données et aux systèmes sur la base du besoin de savoir dans le contexte de leur travail, et rien de plus. Cette méthode - en particulier lorsqu'elle est associée à des principes d'autorisation de confiance zéro - permet d'appréhender toute l'étendue de la surface d'attaque. En réalité, nous devrions appliquer cette même stratégie aux autorisations d'API et à d'autres cas d'utilisation de logiciels en tant que norme. 

La plupart d'entre nous, dans le domaine de la sécurité, sont très conscients du fait que les logiciels sont en train de dévorer le monde, et que le code des systèmes intégrés qui fait fonctionner votre friteuse n'est pas vraiment différent du code qui maintient le réseau électrique en état de marche, en ce qui concerne son potentiel d'exploitation. Nos vies et nos données critiques sont à la merci des acteurs de la menace, et chaque développeur doit comprendre le pouvoir qu'il a de fortifier son code lorsqu'il est correctement formé. Cela nécessite une mise à niveau sérieuse de la culture de sécurité d'une organisation, mais pour une véritable responsabilité partagée de type DevSecOps, les développeurs ont besoin d'une raison de se soucier davantage du rôle qu'ils jouent, et le moyen le plus rapide de changer leur état d'esprit serait peut-être de lier l'accès au dépôt de code à des résultats d'apprentissage du codage sécurisé.

Si nous prenons l'exemple d'une organisation du secteur BFSI, il y a de fortes chances qu'il y ait des référentiels hautement sensibles contenant des données sur les clients ou stockant des informations précieuses telles que des numéros de cartes de crédit. Dans ce cas, pourquoi devrions-nous supposer que chaque ingénieur auquel l'accès a été accordé est sensibilisé à la sécurité, qu'il respecte les exigences strictes de la norme PCI-DSS et qu'il est en mesure d'apporter des modifications à la branche principale rapidement et sans incident ? Bien que cela puisse être le cas pour certains, il serait bien plus sûr de restreindre l'accès à ces systèmes délicats jusqu'à ce que ces connaissances soient prouvées.

Le problème est que, dans la plupart des entreprises, la mise en œuvre d'un scénario de "licence de codage" serait ardue et, en fonction de la solution de formation, un peu trop manuelle pour soutenir tout type d'objectif de sécurité à grande vitesse. Cependant, la bonne combinaison d'une formation intégrative et d'outils peut être au cœur d'une stratégie de sécurité défensive axée sur les développeurs. 

Une intégration efficace de la formation n'est pas impossible.

Trouver des solutions de perfectionnement des développeurs qui complètent à la fois les objectifs commerciaux à grande vitesse et leur flux de travail est la moitié de la bataille, mais faire un effort supplémentaire pour aller au-delà de la formation de conformité de type "one-and-done" est la seule façon de commencer à voir une réduction significative des vulnérabilités au niveau du code. Et pour les développeurs qui réussissent à faire leurs preuves ? Le monde du codage leur appartient et ils n'ont pas à être paralysés par des contrôles de sécurité qui supposent qu'ils ne savent pas naviguer dans les bases. 

L'amélioration des compétences pratiques qui s'intègre de manière transparente à l'environnement de développement fournit le contexte nécessaire pour que les ingénieurs comprennent et appliquent réellement les concepts de codage sécurisé. Ces mêmes intégrations peuvent être utilisées pour gérer efficacement l'accès aux systèmes critiques, en veillant à ce que ceux qui excellent dans leurs résultats d'apprentissage travaillent sans entrave sur les tâches sensibles de la plus haute priorité. Il est également plus facile de mettre en place des récompenses et une reconnaissance, en veillant à ce que les développeurs ayant acquis des compétences en matière de sécurité soient considérés comme une aspiration au sein de leur cohorte. 

Comme beaucoup de choses dans la vie, la fortune sourit aux courageux, et rompre le statu quo pour adopter une approche originale de la vérification des compétences des développeurs est exactement ce dont nous avons besoin pour relever les normes de demain en matière de qualité acceptable du code, sans sacrifier la rapidité.

Une version de cet article a été publiée dans Lecture sombre. Il a été mis à jour et syndiqué ici.


Alors que la plupart des entreprises naviguent dans les flux et reflux de la croissance, de l'innovation et de la transformation numérique, il est tout à fait naturel que certains domaines restent en chantier au fur et à mesure que l'entreprise évolue. C'est souvent le cas du programme de cybersécurité d'une organisation, en particulier lorsque les responsables de la sécurité se battent pour garder une longueur d'avance sur les nouvelles menaces, les vulnérabilités et les développements technologiques qui augmentent l'exposition aux risques.

Cependant, en raison d'une pénurie persistante de compétences, en contradiction avec le déluge de code écrit pour satisfaire les besoins mondiaux en logiciels, de nombreuses entreprises prennent du retard dans leur stratégie de cybersécurité et dans leur infrastructure existante. Et comme l'industrie semble se focaliser sur une approche basée sur les outils, le pouvoir des personnes qualifiées est souvent négligé dans un programme défensif qui fonctionne. 

Il est temps de jeter un regard honnête sur notre maturité globale en matière de cybersécurité et d'évaluer les gains rapides et viables que nous avons sous les yeux.

La maturité durable en matière de cybersécurité est un processus.

Il est facile pour le public de supposer que toutes les entreprises disposent d'un solide programme de cybersécurité et que la protection consiste simplement à sélectionner le bon logiciel et à l'activer comme un bouclier de force pour arrêter les acteurs de la menace dans leur élan. L'année 2022 ayant été l'une des pires années en matière de cyberincidents, avec notamment le rançongiciel du gouvernement du Costa Rica, de nombreux professionnels de la sécurité souhaiteraient que les choses soient aussi simples. 

Alors que de nombreuses industries - en particulier dans le secteur financier - sont axées sur la conformité et liées à des cadres réglementaires de plus en plus complexes qui exigent des mesures de sécurité strictes, la réalité est que la plupart des organisations manquent de cyber-résilience. Plus de la moitié des grandes entreprises dans le monde ne parviennent pas à stopper les cyberattaques, ni à trouver et à corriger rapidement les vulnérabilités exploitées. 

Même les organisations considérées comme avancées, qui disposent d'un programme défini et mature englobant les meilleures pratiques en matière de triple menace, à savoir les personnes, les processus et les technologies, peuvent avoir du mal à suivre le rythme effréné du paysage des menaces. La sensibilisation à la sécurité basée sur les rôles, en particulier pour l'équipe de développement, est un domaine critique dans lequel de nombreuses entreprises ne sont pas à la hauteur. Si chaque membre d'une organisation doit comprendre le rôle qu'il joue dans la réduction de la surface d'attaque, ceux qui manipulent le code jour après jour pourraient être aux commandes d'une approche véritablement transformationnelle de la sécurité... si seulement ils bénéficiaient d'une formation adéquate. 

Un programme de sécurité holistique et défensif exige une amélioration continue et une attention particulière à la mise en place de fondations solides. Si ces fondations sont principalement basées sur des outils, il y a de fortes chances que les niveaux de maturité soient inférieurs à ce que les responsables de la sécurité espèrent. Une étude de l'Institut Ponemon a révélé que 53 % des entreprises n'étaient pas convaincues que leur pile technologique de sécurité pouvait arrêter efficacement les violations, et comme l'erreur humaine est l'une des principales causes des cyberattaques réussies contre les entreprises, grandes et petites, laisser les développeurs à l'écart d'un renforcement stratégique de la sécurité, c'est jouer avec le feu. 

Faire des développeurs le moteur de l'excellence en matière de sécurité des logiciels

L'inconfortable vérité qui entoure les cyberattaques est que, dans presque tous les cas, les attaquants ont un net avantage sur l'entreprise cible, quel que soit le stade auquel elle se trouve dans son parcours de maturité en matière de sécurité. Ils disposent du temps, des outils et de la motivation nécessaires pour rechercher méticuleusement les faiblesses à exploiter, en se consacrant à la percée et à l'atteinte du butin.

Les organisations, en revanche, doivent jongler avec les besoins des entreprises et des clients et, bien qu'elles ne puissent pas se permettre le risque énorme d'une cyberattaque qui les arrêterait, il n'est pas pratique de ralentir les opérations de l'entreprise pour s'adapter à une abondance de contrôles de sécurité qui pourraient finir par entraver les performances. C'est là que les développeurs compétents en matière de sécurité représentent un facteur X dans les résultats de la cyberdéfense.

S'il est établi depuis longtemps que, traditionnellement, les développeurs n'ont pas été en mesure de partager la responsabilité de la sécurité de manière significative, cette situation peut et doit changer pour le mieux. Les organisations peuvent créer des parcours de perfectionnement viables pour la cohorte des développeurs, mais elles doivent sélectionner des options de formation qui fournissent des supports de cours pertinents d'une manière qui ait du sens dans leur monde. Au minimum, les cours devraient être dispensés dans les langages et les cadres qu'ils utilisent activement et aborder les vulnérabilités qu'ils sont le plus susceptibles de rencontrer dans leur base de code. 

Lorsque courses est structuré en tenant compte du flux de travail du développeur, il y a beaucoup plus de chances que les mauvais modèles de codage qui perpétuent les vulnérabilités et les mauvaises configurations courantes puissent être remplacés par de bons modèles sûrs qui augmentent considérablement la qualité des logiciels au fil du temps. Les logiciels de mauvaise qualité ont coûté aux États-Unis 2,41 billions de dollars rien que cette année, et on ne peut y remédier qu'en brisant le cycle d'erreurs qui entretient une dette technique risquée.

Il faut un engagement à l'échelle de l'organisation en faveur d'un programme de sécurité plus positif et holistique, un programme qui exploite le pouvoir des personnes nécessaire pour faire la différence dans les questions qui les concernent. Et s'il est essentiel de ne pas faire les gros titres de demain, l'effort en vaut certainement la peine.

Une version de cet article a été publiée sur Boulevard de la sécurité. Elle a été mise à jour et publiée ici.

Au début de l'année, le Conseil des normes de sécurité PCI a dévoilé la version 4.0 de sa norme de sécurité des données de l'industrie des cartes de paiement (PCI DSS). Bien que les organisations ne devront pas être entièrement conformes à la version 4.0 avant mars 2025, cette mise à jour est la plus transformatrice à ce jour et exigera de la plupart des entreprises qu'elles évaluent (et probablement mettent à niveau) des processus de sécurité complexes et des éléments de leur pile technologique. Cela s'ajoute à la mise en œuvre d'une formation de sensibilisation à la sécurité basée sur les rôles et d'une formation régulière au codage sécurisé pour les développeurs.

Il s'agit là d'une occasion en or pour les entreprises du secteur BFSI d'améliorer sérieusement leurs programmes de sécurité et d'entrer dans une nouvelle ère de cyber-résilience axée sur les personnes. 

Quels sont les plus grands défis à relever pour se préparer à la norme PCI DSS 4.0 ?

Tout comme le programme de sécurité d'une organisation est global, avec des subtilités propres aux besoins de l'entreprise et aux ressources disponibles, les nouvelles normes PCI DSS couvrent beaucoup de terrain. Toutefois, elles révèlent une évolution marquée vers la flexibilité dans les approches visant à satisfaire aux exigences de sécurité, ce qui est important dans un secteur où les outils, les menaces, la stratégie et les mesures de conformité peuvent changer en un instant.

La norme PCI DSS 4.0 adopte le concept selon lequel il existe de nombreuses façons d'atteindre le même objectif de meilleures pratiques de sécurité étanches. C'est vrai, mais cela semble mieux convenir aux organisations ayant une maturité de sécurité avancée et laisse beaucoup de place à l'erreur, en particulier pour celles qui n'ont pas été réalistes dans leur assessment de leur véritable maturité de sécurité interne. En fin de compte, les entreprises doivent être prêtes à s'engager dans la sécurité comme un processus continu et évolutif, et non comme un exercice ponctuel "à mettre en place et à oublier". Une forte culture de la sécurité est indispensable, avec un engagement à l'échelle de l'organisation en faveur de la sensibilisation à la sécurité. 

Quant aux outils au niveau du code - la cohorte de développement - ils doivent être en mesure de fournir des logiciels conformes et sécurisés dans n'importe quel environnement commercial traitant des actifs et des transactions numériques. 

Vos développeurs sont-ils prêts à fournir des logiciels conformes ?

Les développeurs font partie intégrante de l'atteinte d'un état d'excellence en matière de sécurité des logiciels, et cela est particulièrement pertinent pour aller au-delà de la simple conformité symbolique à la norme PCI DSS. Il est essentiel que les développeurs comprennent l'image plus large de PCI DSS 4.0 en termes de ce qu'ils peuvent contrôler et intégrer dans leur approche par défaut de la création d'un logiciel. 

Les changements les plus importants pour l'équipe de développement se situent dans trois domaines clés, qui peuvent être décomposés comme suit :

• Authentification : Un plan viable de contrôle d'accès a toujours été un élément clé de la conformité PCI, mais la version 4.0 donne un coup d'accélérateur qui nécessitera une mise en œuvre minutieuse, tant en interne qu'en externe. L'authentification multifactorielle (MFA) deviendra la norme, tout comme les règles renforcées concernant la complexité des mots de passe et les délais d'attente.
  
  Les problèmes de sécurité liés à l'authentification et au contrôle d'accès étant désormais les plus courants auxquels le développeur moyen est susceptible d'être confronté, il est impératif qu'une formation précise soit mise en place pour l'aider à identifier et à résoudre ces problèmes dans le code réel.
  
  
• Chiffrement et gestion des clés : Nous vivons dans un monde où nous pouvons accéder à certaines de nos informations les plus sensibles via de multiples points d'accès, comme nos services bancaires en ligne. Ces données de grande valeur étant menacées, le cryptage et des pratiques de cryptographie rigoureuses sont indispensables. Les développeurs doivent s'assurer qu'ils disposent de connaissances actualisées sur les lieux de transmission des informations, sur la manière dont les utilisateurs peuvent y accéder et, même dans le cas où elles se retrouveraient entre de mauvaises mains, s'assurer qu'elles sont illisibles pour les acteurs de la menace.
  
  
• Logiciels malveillants : dans les lignes directrices précédentes, les contrôles de sécurité relatifs à la protection des logiciels contre les codes malveillants étaient appelés "logiciels antivirus", mais cela simplifie à l'excès ce qui devrait être une approche multicouche protégeant contre bien plus que les seuls virus. Les solutions anti-programmes malveillants doivent être appliquées partout où cela est nécessaire, et la journalisation et la surveillance continues sont obligatoires.
  
  Il est également essentiel que les développeurs aient des parcours d'apprentissage qui couvrent l'identification des composants vulnérables, en particulier avec la plupart des bases de code qui reposent au moins en partie sur du code tiers.

Qu'est-ce qui constitue une formation "suffisante" pour les développeurs ?  

Comme les recommandations précédentes, la norme PCI DSS 4.0 propose que les développeurs soient formés "au moins" une fois par an. Cependant, si l'on considère qu'une fois par an est un point de contact suffisant pour la création de logiciels sécurisés, on est loin du compte et il est peu probable que l'on obtienne des logiciels plus sûrs et conformes. 

La formation des développeurs devrait commencer par une formation de base au Top 10 de l'OWASP, ainsi qu'à toutes les autres vulnérabilités qui sont pertinentes pour le langage et critiques pour l'entreprise. Cela devrait faire partie d'un programme continu, dans le but de continuer à développer ces compétences et d'intégrer la sécurité non seulement dans le développement de logiciels dès le départ, mais aussi dans leur état d'esprit et leur approche de leur rôle. En outre, les rôles et les responsabilités doivent être parfaitement clairs pour la cohorte de développeurs et leurs responsables. La sécurité doit être une responsabilité partagée, mais il n'est que juste de documenter les attentes et de s'assurer qu'elles peuvent être satisfaites correctement.

Avec le temps disponible pour se préparer à la conformité PCI DSS 4.0, il est possible de faire des progrès significatifs dans l'amélioration de la culture de la sécurité à l'échelle de l'organisation, ce qui constitue un terrain fertile pour développer la cohorte de développement la plus sensibilisée à la sécurité que vous n'ayez jamais eue.

‍