Información sobre el código de seguridad

Pour adopter une approche proactive de la sécurisation de vos logiciels, vous devez rester à la pointe des dernières normes et exigences de conformité. Après tout, le paysage de la cybersécurité est constamment en mouvement avec de nouvelles menaces et vulnérabilités, en particulier à mesure que de nouvelles technologies apparaissent. Cela n'a jamais été aussi vrai qu'aujourd'hui, alors que nous nous trouvons collectivement à un point d'inflexion de l'IA où de nouvelles évolutions et de nouveaux cas d'utilisation semblent émerger chaque jour.

Pour relever ces défis, la Fondation OWASP a récemment publié sa version mise à jour du Top 10 de l'OWASP pour les applications LLM (Large Language Model), qui vise à informer les développeurs, les architectes et les autres contributeurs à la fourniture de logiciels des risques potentiels liés au déploiement de LLM et d'applications d'IA générative. Chez Secure Code Warrior, nous sommes ravis d'annoncer que les modifications et les mises à jour de cette dernière version sont déjà mises en œuvre et disponibles sur notre plateforme d'apprentissage du code sécurisé. Grâce à ces documents récemment disponibles et mis à jour, tous nos utilisateurs peuvent rester à la pointe de l'atténuation des risques lors de l'utilisation des LLM.

Quelles sont les nouveautés de cette mise à jour ?

L'OWASP a retiré deux articles de son précédent Top 10 :

• Conception de plug-in non sécurisée - qui concerne la manière dont les LLM interagissent avec les plugins et la manière dont les plugins interagissent avec le stockage ou les services externes.
• Vol de modèles - faisant référence à la réplication ou à l'acquisition non autorisée de modèles d'apprentissage automatique ou de systèmes d'IA.

Conformément aux versions précédentes du Top 10 de l'OWASP, Secure Code Warrior avait Directives associés à ces vulnérabilités dans le cadre de notre cours LLM Top 10. Ces directives, qui fournissent des informations faciles à comprendre sur les vulnérabilités et les concepts de sécurité dans un format facile à comprendre et lisible, ont depuis été supprimées du programme du cours. Cependant, les directives restent disponibles dans Explore, de même que tous les autres supports pédagogiques que nous proposons.

En maintenant son Top 10 à un niveau officiel de 10, l'OWASP a ajouté deux nouveaux articles :

• Fuite rapide du système - où les instructions généralement masquées qui guident le comportement d'un modèle sont exposées aux utilisateurs.
• Vecteur et intégration - qui peuvent exposer des informations spécifiques, exclusives ou en temps réel qui ne sont pas accessibles au public

Des directives concernant ces vulnérabilités ont été ajoutées au cours LLM Top 10, et tout comme les directives qui ont été supprimées, ces deux directives sont également accessibles dans Explore pour les utilisateurs qui souhaitent tirer parti de l'apprentissage à leur propre rythme.

Enfin, l'OWASP a également apporté quelques modifications aux catégories de vulnérabilités existantes dans sa liste, en renommant certaines catégories pour qu'elles soient plus complètes ou spécifiques, et en modifiant leurs définitions. Nos directives relatives à ces sujets ont maintenant été mises à jour pour refléter à la fois les modifications mineures apportées par rapport aux directives de l'OWASP ainsi que les nouvelles conventions de dénomination. De plus, leur liste par ordre de priorité a été mise à jour pour correspondre à l'ordre défini dans le Top 10 de l'OWASP LLM.

Chez Secure Code Warrior, nous nous engageons à aider nos utilisateurs à garder une longueur d'avance. Les dernières mises à jour de l'OWASP étant déjà reflétées dans notre plateforme d'apprentissage agile, nous avons permis à nos utilisateurs d'accéder facilement à des supports de formation à jour qui couvrent les vulnérabilités les plus récentes et atténuent les risques lors du déploiement des technologies LLM et Generative AI. Que vous souhaitiez faire face aux menaces récemment introduites que sont les fuites rapides du système ou les vecteurs et l'intégration, ou que vous mettiez à jour votre compréhension de la désinformation et de la consommation illimitée, notre plateforme fournit les ressources dont vous avez besoin pour maîtriser ces concepts essentiels et améliorer votre posture de sécurité.

Saviez-vous que 67 % des développeurs admettent avoir envoyé du code comportant des vulnérabilités ? Imaginez une équipe d'ouvriers chargés de construire une maison. Ils disposent de tous les matériaux et outils dont ils ont besoin, mais ils ont du mal à suivre les plans et les codes du bâtiment. Par conséquent, ils font des erreurs et la maison n'est pas construite selon le code.

Cette analogie peut être utilisée pour illustrer les défis auxquels sont confrontés les développeurs lorsqu'ils essaient de pratiquer le codage sécurisé. Tout comme les ouvriers du bâtiment doivent suivre les plans et les codes du bâtiment pour garantir la sécurité de leurs maisons, les développeurs doivent suivre des pratiques de codage sécurisées pour garantir la sécurité de leurs applications logicielles.

Il existe un certain nombre de raisons pour lesquelles le codage sécurisé peut être difficile. Il s'agit notamment de :

• Manque de sensibilisation aux pratiques de codage sécurisé. 86 % des développeurs déclarent qu'il leur est difficile de pratiquer un codage sécurisé.‍
• Manque de temps et de ressources. 24 % des personnes interrogées dans le cadre de notre enquête ont déclaré que le « manque de temps » était le principal obstacle à l'intégration du code sécurisé.‍
• La complexité du codage sécurisé. 63 % des développeurs estiment qu'il est difficile d'écrire un code sécurisé exempt de vulnérabilités.‍
• Dépendance excessive à l'égard des outils. 57 % des équipes de sécurité des applications utilisent six outils ou plus pour découvrir les vulnérabilités au cours du cycle de vie de DevSecOps. (GitLab, 2023)

Cependant, malgré les défis, un codage sécurisé est essentiel. En suivant des pratiques de codage sécurisées, les développeurs peuvent contribuer à protéger leurs applications contre les vulnérabilités susceptibles d'être exploitées par des attaquants. Tout comme une maison bien construite est moins susceptible de s'effondrer, une application bien codée est moins susceptible d'être piratée.

Voici quelques conseils pour les développeurs qui souhaitent améliorer leurs pratiques de codage sécurisé :

• Bénéficiez d'une formation et d'une formation sur le codage sécurisé. Un certain nombre de ressources sont disponibles pour aider les développeurs à se familiariser avec les pratiques de codage sécurisé.
• Utilisez des outils d'analyse statique pour identifier les vulnérabilités du code. Les outils d'analyse statique peuvent aider à identifier les vulnérabilités du code qui peuvent être difficiles à détecter manuellement.
• Rédigez un code facile à réviser et à comprendre. Un code facile à consulter et à comprendre est plus susceptible d'être un code sécurisé.
• Testez le code de manière approfondie. Les tests de code peuvent aider à identifier et à corriger les vulnérabilités avant qu'elles ne soient exploitées.

Vous souhaitez en savoir plus ? Découvrez les secrets du développement d'une stratégie de codage agile et sécurisée grâce à notre plan d'apprentissage du code sécurisé.

‍

‍

‍

‍

Une version de cet article a été publiée sur Boulevard de sécurité. Il a été mis à jour et diffusé ici.

Plus tôt cette 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). Les entreprises n'auront pas besoin d'être entièrement conformes à la version 4.0 avant mars 2025, mais cette mise à jour est la plus transformatrice à ce jour et obligera la plupart des entreprises à évaluer (et probablement à mettre à niveau) des processus de sécurité complexes et des éléments de leur infrastructure 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.

Cela représente une occasion en or pour les entreprises de l'espace BFSI d'améliorer sérieusement leurs programmes de sécurité, ouvrant ainsi la voie à une nouvelle ère de cyberrésilience axée sur les personnes.

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

Tout comme le programme de sécurité d'une entreprise est complet, avec des complexités propres à ses besoins commerciaux et aux ressources disponibles, les nouvelles normes PCI DSS couvrent de nombreux domaines. Cependant, ils révèlent une évolution marquée vers la flexibilité dans les approches visant à répondre aux exigences de sécurité, et dans un secteur où les outils, les menaces, la stratégie et les mesures de conformité peuvent changer en un instant, cela est significatif.

La norme PCI DSS 4.0 repose sur le concept selon lequel il existe de nombreuses manières d'atteindre le même objectif en matière de bonnes pratiques de sécurité. C'est vrai, mais cela semble mieux adapté 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 évalué de manière réaliste leur véritable maturité en matière de sécurité interne. En fin de compte, les entreprises doivent être prêtes à s'engager dans la sécurité en tant que processus continu et évolutif, et non en tant qu'exercice ponctuel « à repartir et oublier ». Une solide culture de sécurité est indispensable, avec un engagement à l'échelle de l'organisation en faveur de la sensibilisation à la sécurité.

Et ceux qui utilisent des outils au niveau du code, c'est-à-dire la cohorte de développement, doivent être en mesure de fournir des logiciels conformes et sécurisés dans tout environnement commercial gérant des actifs et des transactions numériques.

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

Les développeurs jouent un rôle essentiel dans l'atteinte d'un niveau d'excellence en matière de sécurité logicielle, et cela ne se limite pas à la simple conformité à la norme PCI DSS symbolique. Il est essentiel que les développeurs comprennent la vision globale de la norme PCI DSS 4.0 en termes de ce qu'ils peuvent contrôler et intégrer dans le cadre de leur approche par défaut lors de la conception d'un logiciel.

Trois domaines clés représentent les changements les plus pertinents pour l'équipe de développement, et ils peuvent être répartis comme suit :

• Authentification : Un plan viable pour le contrôle d'accès a toujours été un élément clé de la conformité PCI, mais la version 4.0 va encore plus loin, d'une manière qui nécessitera une mise en œuvre minutieuse à la fois en interne et en externe. L'authentification multifactorielle (MFA) deviendra la norme, tout comme le renforcement des règles relatives à la complexité des mots de passe et aux délais d'expiration.
  
  Les problèmes de sécurité liés à l'authentification et au contrôle d'accès étant désormais les problèmes les plus courants auxquels est confronté votre développeur moyen, il est impératif de mettre en place une formation de précision pour l'aider à identifier et à résoudre ces problèmes dans le code réel.
  
  
• Chiffrement et gestion des clés : Nous opérons dans un monde où nous pouvons accéder à certaines de nos informations les plus sensibles via plusieurs points d'accès, tels que nos services bancaires en ligne. Ces données de grande valeur étant menacées, le cryptage et de solides pratiques de cryptographie sont indispensables. Les développeurs doivent s'assurer de disposer de connaissances à jour sur l'endroit où les informations sont transmises, sur la manière dont les utilisateurs peuvent y accéder et, même si elles tombent entre de mauvaises mains, en veillant à ce qu'elles soient illisibles pour les acteurs de la menace.
  
  
• Logiciels malveillants : Dans les directives précédentes, les contrôles de sécurité relatifs à la protection des logiciels contre les codes malveillants étaient qualifiés de « logiciels antivirus », mais cela simplifie à l'extrême ce qui devrait être une approche multicouche protégeant contre bien plus que les seuls virus. Des solutions anti-malware doivent être appliquées chaque fois que cela est nécessaire, et une journalisation et une surveillance continues sont obligatoires.
  
  Il est également essentiel que les développeurs disposent de parcours d'apprentissage qui couvrent l'identification des composants vulnérables, en particulier lorsque la plupart des bases de code s'appuient au moins en partie sur du code tiers.

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

À l'instar des 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 cela implique qu'une fois par an constitue un point de contact suffisant pour la création sécurisée de logiciels, cela est loin d'être suffisant et il est peu probable qu'il aboutisse à des logiciels plus sûrs et conformes.

La formation des développeurs doit commencer par une formation de base dans le Top 10 de l'OWASP, ainsi que par toute autre vulnérabilité pertinente en termes de langage et critique pour l'entreprise. Cela devrait faire partie d'un programme permanent, dans le but de continuer à développer ces compétences et à intégrer la sécurité non seulement dans le développement des logiciels dès le départ, mais également dans leur état d'esprit et leur approche de leur rôle. En outre, les rôles et les responsabilités doivent être clairement définis pour la cohorte de développement et ses responsables. La sécurité doit être une responsabilité partagée, mais il est juste de documenter les attentes et de s'assurer qu'elles peuvent être satisfaites correctement.

Compte tenu des délais impartis pour se préparer à la conformité à la norme PCI DSS 4.0, il est possible de réaliser des progrès significatifs en matière d'amélioration de la culture de sécurité à l'échelle de l'entreprise, et c'est un terrain fertile pour former la cohorte de développeurs la plus attentive à la sécurité que vous ayez jamais eue.

‍

Chez Secure Code Warrior, nous innovons constamment pour aider les développeurs et les organisations à acquérir les compétences nécessaires pour relever les défis de sécurité en constante évolution d'aujourd'hui. Nous y parvenons grâce à une activation du code sécurisé très engageante, flexible et facile à gérer.

Tout le monde souhaite obtenir un bon retour sur investissement lorsqu'il s'agit d'investir dans sa technologie ou dans des programmes de formation supplémentaires. Mais en matière de sécurité, vous devez jouer un long jeu. Investir dans une sécurité pilotée par les développeurs permettra non seulement d'atténuer le risque de violations coûteuses, de perte de productivité et d'accumulation de dettes technologiques, mais aussi de créer une stratégie proactive et rentable pour garder une longueur d'avance sur le paysage des menaces actuel.

Au cours du dernier trimestre, Secure Core Warriors a mis en œuvre de nouvelles méthodes d'apprentissage avec Coding Labs, qui est désormais disponible pour tous les clients de Secure Code Warrior. Nous sommes ravis d'annoncer des améliorations apportées à la gestion des participations et à la gestion des versions des cours, et nous avons créé de nouvelles activités de cours, telles que les Directives !

¡Vamos a descubrir más!

Ampliar el alcance y la profundidad de la plataforma SCW.

La continua expansión de Secure Code Warrior nuevos contenidos permite mantener la relevancia, la actualidad y la adaptación de nuestros módulos a lo que usted necesita saber en el panorama actual de la ciberseguridad. Con una amplitud y profundidad punteras en más de 55 idiomas, es fácil crear y desarrollar un programa para formar a desarrolladores en un gran número de lenguajes y marcos de trabajo.

Directives de codage disponibles dans les cours

L'ajout de directives offre aux développeurs un apprentissage contextuel et à leur propre rythme qui couvre principalement l'atténuation de la sécurité. Les directives sont plus détaillées que les vidéos et se concentrent sur un langage ou un cadre spécifique. D'autres activités offensives telles que les défis, les missions et les procédures pas à pas nécessitent déjà que les développeurs comprennent la vulnérabilité. Nous avons créé des directives pour compléter ces activités d'un point de vue défensif.

Les développeurs peuvent lire les directives dans les cours, et les administrateurs peuvent les utiliser dans les modèles de cours. Les directives couvrent les vulnérabilités répertoriées dans le Top 10 2021 de l'OWASP et contiennent des extraits de code en C#, Java, JavaScript, Python, Pseudocode et PHP.

Nouveau contenu du Défi

Secure Code Warrior est régulièrement mis à jour et crée de nouveaux défis pertinents, opportuns et adaptés aux besoins de votre organisation. Nous sommes ravis d'annoncer des défis élargis disponibles dans les domaines suivants :

• Dart : Flutter - un langage mobile pour créer des applications multiplateformes fluides sur Android et iOS
• Terraform : GCP - une infrastructure en tant que langage de développement de code pour Google Cloud Provide.

Les développeurs peuvent analyser le code, trouver la vulnérabilité et faire preuve d'esprit critique pour choisir la meilleure implémentation de sécurité afin de prévenir les vulnérabilités répertoriées.

Prochainement : nouveau contenu pour développeurs frontaux

Les développeurs frontaux ont également besoin d'une activation sécurisée du code ! C'est pourquoi nous publierons des vulnérabilités frontales supplémentaires dans les missions et les procédures pas à pas. Les développeurs frontaux pourront également accéder à des missions spécifiques au front-end dans les cours.

Ces mises à jour visent à couvrir de manière exhaustive les vulnérabilités spécifiques au frontend, qu'il s'agisse de vulnérabilités courantes, comme le XSS basé sur DOM, ou de vulnérabilités moins fréquemment rencontrées, telles que l'injection CSS.

Des procédures pas à pas fourniront aux développeurs frontaux des conseils fiables sur la manière dont les vulnérabilités sont exploitées. Les développeurs avancés pourront également tester leurs compétences dans le cadre de missions frontales lors de tournois.

Simplifier l'expérience des administrateurs et des développeurs

La configuration d'un programme de formation au code sécurisé évolutif et engageant est désormais plus facile que jamais grâce aux principales améliorations apportées à la plate-forme en termes d'utilisabilité.

‍

Versionnage des cours, archivage et gestion de la participation

Désormais, suivez les besoins en constante évolution des programmes d'une organisation grâce à de nouvelles méthodes de modification des programmes existants. Le versionnage des cours permet aux administrateurs de modifier leurs cours existants sans avoir à créer un tout nouveau cours. Les administrateurs peuvent également supprimer des cours de test ou des cours auxquels aucun développeur n'est inscrit, ce qui les aide à désencombrer leurs archives.

En outre, la possibilité d'appliquer des filtres supplémentaires sur la page Gestion des cours permettra aux administrateurs de filtrer plus facilement jusqu'au cours sur lequel ils souhaitent travailler. Les cours peuvent être filtrés selon un certain nombre d'attributs tels que le statut du cours, la date de fin et les équipes inscrites. Par exemple, les administrateurs peuvent facilement localiser tous les cours dont la durée est limitée, auxquels est jointe une évaluation de fin de cours, ou si le cours est à l'état de brouillon ou d'aperçu.

Outre la gestion des versions et le filtrage des cours, les administrateurs peuvent désormais réinviter les participants au cours en masse et les supprimer d'un cours si nécessaire. Cela donne aux administrateurs une solution en un clic pour réinviter les développeurs dans l'état « invité », économisant ainsi un temps et une énergie précieux pour leur rappeler de revenir sur la plateforme et de commencer à apprendre !

‍

C'est la fin des nouvelles fonctionnalités de ce trimestre ! Suivez Secure Code Warrior sur Twitter pour obtenir des mises à jour sur les dernières versions et améliorations.

Vous souhaitez essayer Secure Code Warrior mais vous n'avez pas encore de compte ? Inscrivez-vous pour un compte d'essai gratuit aujourd'hui pour commencer.

En esta ocasión anual tan festiva para los profesionales de la ciberseguridad, el Mes Nacional de la Concienciación sobre la C iberseguridad es un momento que muchas empresas utilizan para reflexionar y evaluar el ritmo general de la concienciación sobre la seguridad en toda la organización. Y con el 62% de las empresas que experimentaron un ataque de phishing o ingeniería social solo en 2018, no se puede exagerar la importancia de garantizar que cada individuo en la empresa, ya sea en un papel de seguridad o no, tenga una formación adecuada de concienciación sobre la ciberseguridad.

Como evento cada vez más global, el mes representa un punto de encuentro para discutir las mejores prácticas, y las iniciativas son deliberadamente superficiales. Sin embargo, incluso las organizaciones con sólidos programas de seguridad y especialistas internos pueden aprovechar este momento para evaluar a los equipos más técnicos en cuanto a lo que necesitan para ser más conscientes de la seguridad en el contexto de su función.

Para los especialistas en seguridad de las aplicaciones, los líderes de los equipos de desarrollo y los miembros más expertos en seguridad de la cohorte de ingenieros, puede parecer un poco como si les enseñaran a chupar huevos, pero son estos campeones dentro de la empresa los que pueden llevar la seguridad y la protección a nuevas cotas, en toda la empresa.

Cómo elevar el mes de la concienciación sobre la ciberseguridad

Esta es una oportunidad de oro para que el equipo de seguridad extienda una especie de rama de olivo al equipo de desarrollo, quizás en forma de actividades y programas entre equipos que puedan ayudar a los desarrolladores a sentirse más positivos respecto a la seguridad en el contexto de su trabajo.

Algunas ideas de inicio son:

1. Ayude a los desarrolladores a obtener el apoyo que necesitan para aprender a codificar de forma segura. No disponer de las herramientas adecuadas para el trabajo es una buena manera de justificar el hecho de que una tarea sea demasiado difícil. Si los desarrolladores no tienen la formación y las herramientas adecuadas para considerar la seguridad como una prioridad en el proceso de codificación, no es de extrañar que muchos equipos estén mal equipados para mantener las vulnerabilidades comunes fuera de su código.
   
   Aprovecha este mes para entender qué falta en la pila tecnológica de desarrollo, qué gestores pueden trabajar juntos para mejorar la comunicación y aumentar la visibilidad de la seguridad, y quién puede seguir defendiendo y defendiendo la seguridad en el futuro.
   
2. Organice un evento "Lunch and Learn". Las comunidades de ciberseguridad y desarrollo están, en general, repletas de gente increíblemente generosa que está encantada de compartir su experiencia. Ponte en contacto con los ponentes de las conferencias, los compañeros de tecnología de otras empresas o incluso los capítulos locales de OWASP, y mira quién podría venir a charlar con el equipo o grabar un seminario web con alguien de la organización. Es una ganancia relativamente rápida, y puede ser un gran beneficio para los desarrolladores prometedores para ver diferentes vías de carrera de seguridad en frente de ellos.
   
3. Reúnete para una competición amistosa. Aprender sobre seguridad es mucho más divertido cuando se hace algo un poco diferente y especial. La codificación segura tournaments es una forma estupenda de que los desarrolladores pongan a prueba sus habilidades de codificación segura y compitan con sus compañeros en un entorno de juego. Organiza un concurso de disfraces y sé creativo con los equipos (¿qué tal si los desarrolladores se enfrentan a sus jefes?). Pida pizza y bebidas, y ponga música enérgica, y puede ser un evento para recordar para toda la organización.

Retribuir a la comunidad: Descargue su aplicación gratuita Secure Code Bootcamp

Yo mismo soy desarrollador y siempre hemos buscado lo que podemos compartir y utilizar de forma gratuita. Es un orgullo hacer algún programa gratuito que pueda ayudar a los demás, y este mes es un buen momento para reflexionar sobre nuestras raíces y ver lo que podemos aportar a la comunidad.

Para ello, nos complace anunciar nuestra nueva aplicación gratuita, Secure Code Bootcamp. Se trata de un compañero de codificación segura de bolsillo para los programadores que quieran desafiarse a sí mismos, aumentando progresivamente su conciencia de la seguridad en cualquier lugar y en cualquier momento.

Descargue ahora la aplicación para iOS y Android y aprenda a localizar e identificar las vulnerabilidades OWASP en Node.JS, Python:Django, Java:Spring, C# .NET: MVC:

Ce n'est un secret pour personne que notre mission principale est de sécuriser les logiciels et leur développement, en tenant compte de la sécurité dès le début de la production. Notre vision établit une nouvelle référence en matière de création de logiciels, où les développeurs disposent des compétences et des connaissances nécessaires pour détecter les codes vulnérables pendant le processus d'écriture et corrigez-le avant même que cela ne devienne un problème.

Dans cette optique, vous pouvez penser que nous sommes ravis d'apprendre que de nouvelles violations de données, cyberattaques et codes exploités touchent des entreprises du monde entier. Ces incidents soulignent certainement la nécessité de notre service dans de nombreux secteurs verticaux. À vrai dire, c'est assez frustrant. Il est clair qu'en tant qu'industrie, nous commettons les mêmes erreurs à maintes reprises, car la plupart des formations en matière de sécurité ne sont tout simplement pas suffisamment solides pour minimiser les risques et mettre fin à ces violations.

La dernière victime d'une violation de données est Ticketmaster. Si vous faisiez partie des milliers de clients concernés, vous auriez reçu un e-mail vous informant de l'incident et vous demandant de modifier votre mot de passe. Personne ne s'attend à ce que ses données personnelles soient violées simplement pour l'achat de billets pour un concert ou un événement sportif, et pourtant nous y sommes.

C'est une situation terrible pour tout le monde, qui nuit à la réputation de Ticketmaster et qui nuit carrément à l'expérience client. Il y a cependant un problème : ce n'était pas entièrement de leur faute.

Vous voyez, l'entreprise a utilisé les services d'une application de support client tierce d'Inbenta Technologies. Ticketmaster UK a découvert que le produit contenait un code malveillant, ce qui a compromis 5 % des données de ses clients mondiaux.

Et comment exactement les hackers ont-ils réussi à exploiter ce système ? Ils a manipulé une seule ligne de code JavaScript, personnalisé par Inbenta Technologies pour répondre aux besoins de Ticketmaster. Selon Inbenta, le code a été utilisé sur une page pour laquelle il n'a pas été créé et, s'ils l'avaient su, ils l'auraient identifié comme une faille de sécurité.

La vulnérabilité elle-même est essentiellement un problème de sécurité de la bibliothèque de chargement/stockage de fichiers, dans lequel une seule violation peut affecter tous les sites sur lesquels le même code est chargé. Le code peut être modifié pour collecter et rediriger les données personnelles vers les attaquants, pour commencer. Il s'agit d'un exploit simple avec un potentiel de dégâts considérable, contre lequel nous nous efforçons de nous défendre avec un gamme d'exercices d'entraînement intégrés à la plateforme pour les développeurs.

Bien entendu, il est pratiquement impossible de gérer une entreprise sans recourir à certaines applications tierces. Cependant, vous n'avez aucun contrôle sur la façon dont ils conçoivent leurs logiciels, et vous n'avez pratiquement aucune visibilité sur la sécurité de leur code. Cela devient un exercice de confiance. Si votre partenaire tiers fait preuve de laxisme dans ses pratiques de codage sécurisé, vous êtes peut-être en train d'ouvrir la porte à une violation de votreentreprise.

Alors, quelle est la solution ? En termes simples : nous devons tous faire mieux. Il faut arrêter de considérer la sécurité comme un obstacle gênant sur la voie de l'innovation des entreprises.

Il est plus facile que vous ne le pensez de fournir à votre équipe de développement les bons outils et les bonnes connaissances pour adopter la sécurité et stopper les mauvais codes. Nous avons été ravis de voir un si grand nombre des plus grandes et des plus connues entreprises du monde dans les domaines de la finance, des télécommunications, de la vente au détail et de la technologie adopter cette nouvelle approche, mais les entreprises du Fortune 100 ne devraient pas être les seules à prendre des mesures en matière de formation à la sécurité. Toutes les entreprises qui comptent des développeurs parmi leur personnel doivent mettre en place une formation pour aider les équipes à coder en toute sécurité.

Le livre blanc récemment publié que j'ai écrit en collaboration avec notre directeur technique Matias Madou présente les avantages de la création d'une culture de sécurité au sein de votre organisation. Nous expliquons pourquoi c'est la clé pour débloquer l'innovation, rester agile et réduire l'impact financier d'un code non sécurisé.

Vous y trouverez des conseils, notamment :

* Comment rendre la formation à la sécurité pertinente et intéressante pour les développeurs

* Comment apprendre aux développeurs à identifier et à résoudre leurs propres problèmes

* Comment aider les développeurs à créer leur propre code en toute sécurité.

Je vous invite à téléchargez cette ressource et utilisez-le pour renforcer la sécurité au sein de votre organisation, renforcer les compétences de votre équipe et être à l'avant-garde de l'établissement de normes de code plus strictes.

Il faut arrêter de considérer la sécurité comme un obstacle gênant sur la voie de l'innovation des entreprises.

Si je vous demandais combien coûterait la modification d'une seule ligne de code informatique sur un appareil déjà en service, quel chiffre me viendrait à l'esprit ? Quelques centaines de dollars ? Peut-être des milliers ?

Selon Aviation Today, coûte 1 million de dollars pour qu'une compagnie aérienne commerciale mette à jour une ligne de code dans ses avions. Pour un coût aussi élevé, ils auraient probablement besoin d'une raison impérieuse pour prendre les mesures nécessaires pour mettre à jour les systèmes de leur avion, ce qui m'a vraiment fait réfléchir à un certain nombre de facteurs.

Décomposer les coûts

Bien que l'article ne précise pas en quoi consiste le coût d'un million de dollars, je pense que c'est un chiffre viable. Je ne suis pas un expert spécifique des mises à jour logicielles des compagnies aériennes, mais je peux supposer certaines des mesures que la compagnie aérienne est obligée de prendre dans cette situation.

Tout d'abord, la compagnie aérienne doit découvrir une faille ou une vulnérabilité nécessitant la mise à jour. L'exemple cité concerne les recherches effectuées par le département américain de la Sécurité intérieure (DHS) sur un Boeing 757. Les résultats, à savoir un piratage à distance après seulement deux jours de travail, sont suffisamment convaincants pour que n'importe quelle compagnie aérienne en prenne note.

À partir de là, les développeurs de logiciels doivent analyser les résultats, écrire un nouveau code et le tester dans un environnement sûr pour s'assurer que le problème est résolu. Vient maintenant la partie la plus délicate. La compagnie aérienne doit immobiliser au sol chaque avion vulnérable ou défectueux, appliquer le nouveau code, le tester pour s'assurer qu'il fonctionne avec cet avion spécifique, puis recertifier ce plan pour les vols commerciaux.

Selon airfleets.net, Southwest Airlines compte actuellement 499 Boeing 737-700 dans sa flotte. Pensez à l'investissement en temps et en argent que cela impliquerait si une faille de sécurité apparaissait dans ce modèle d'avion en particulier.

Ce n'est pas simplement un défi pour les compagnies aériennes

De toute évidence, les compagnies aériennes devraient avoir tout intérêt à utiliser des principes de codage sûrs et solides dès le départ. Après y avoir réfléchi quelques instants, j'ai découvert de nombreux secteurs et situations où des coûts similaires pourraient s'appliquer. Au lieu de vous inquiéter des avions qui tombent du ciel à cause d'une vulnérabilité piratée, qu'en est-il dispositifs médicaux tels que les stimulateurs cardiaques? Combien coûte le rappel et la mise à jour d'un demi-million de pièces électroniques vitales ?

Dans l'industrie automobile, nous continuons d'entendre des discussions et des préoccupations en matière de sécurité à propos des voitures autonomes. Pourtant, même nos véhicules « classiques » dépendent plus que jamais de la connectivité à Internet, ce qui soulève des problèmes : si divertissant - problèmes de sécurité.

Il est évident que la mise à jour des appareils ou des systèmes après leur sortie dans un environnement de production, ou avant leur production en série, demande plus d'efforts et de temps que de renforcer la sécurité dans votre processus de développement initial. Pourtant, nous continuons de constater chaque jour de nouvelles failles logicielles et vulnérabilités de cybersécurité évitables, ce qui souligne la nécessité pour les entreprises de rechercher des moyens de créer un développement logiciel sécurisé dans leur culture du développement.

La modification d'une ligne de code sur un équipement avionique coûte 1 million de dollars et sa mise en œuvre prend un an. Pour Southwest Airlines, dont la flotte est basée sur les 737 de Boeing, elle « mettrait en faillite » si une cybervulnérabilité était spécifique aux systèmes embarqués sur les 737

‍

Plus tôt ce mois-ci, j'ai eu l'occasion d'assister Journée OWASP AppSec 2019 dans la belle ville de Melbourne. Ces événements destinés aux développeurs figurent parmi mes événements préférés du calendrier ; ils me rappellent avec humilité la communauté qui travaille sans relâche pour former et responsabiliser les ingénieurs et les spécialistes en logiciels afin qu'ils défendent la sécurité dans leur travail.

La liste des invités était sensationnelle, sans parler d'une diversité rafraîchissante, et je suis heureuse de pouvoir repartir inspirée, même après toutes ces années passées dans l'industrie. Des personnes comme Tanya Janca, Tony James et Teri Radichel a fait des présentations incroyables, tandis que Wireghoul« Les défis de codage sécurisé d'Eldar Marcussen ont testé sur place l'ensemble de l'auditorium, mais c'était formidable d'assister à une telle sensibilisation à la sécurité parmi les participants.

Cette année, Secure Code Warrior était un sponsor platine de l'événement. J'ai eu le sourire aux lèvres en me rappelant qu'il y a tout juste quatre ans, c'était l'équipe à l'origine de l'OWASP AppSec Day qui avait aidé notre start-up en lançant un stand gratuit et en proposant une promotion. C'était un moment de fierté de voir le chemin que nous avions parcouru en tant qu'entreprise et d'être reconnaissante de l'existence d'une communauté aussi généreuse composée de personnes incroyables.

Toni James : la sécurité du point de vue du développeur

S'il y a une chose que nous devons développer davantage dans ce monde, c'est l'empathie. Et lorsqu'il s'agit de rendre les logiciels plus sûrs à tous les niveaux, il est essentiel de comprendre la situation des développeurs.

J'ai beaucoup apprécié la présentation de Toni, et je suis sûr qu'elle a été immédiatement accessible à tous les développeurs. L'histoire ne se limite pas à « écrire du code sécurisé », et même si je suis convaincue que les développeurs bien formés à la sécurité constituent notre meilleure chance de lutter contre les vulnérabilités, il est impératif de prendre en compte leurs défis quotidiens.

Le travail d'un développeur de logiciels peut être présenté à des millions d'utilisateurs, prendre en charge des infrastructures critiques et être la force motrice des services que nous tenons pour acquis. La création de fonctionnalités, la mise en œuvre d'innovations commerciales et le respect de délais de livraison serrés créent une forte pression, et ce, avant qu'une équipe AppSec ne prenne une place importante et ne se consacre à son dur labeur. Toni a parlé de la vie dans cet environnement et de la façon dont une bonne dose d'empathie de la part de tous peut mener à de bien meilleurs processus et à de meilleurs résultats en matière de sécurité. Je suis très heureuse de constater que de tels progrès ont été réalisés pour combler le fossé entre les développeurs et les équipes AppSec ; en fin de compte, il s'agit d'un élément essentiel d'une culture de sécurité positive et florissante, et Toni est un excellent exemple de ce processus qui fonctionne incroyablement bien.

Tanya Janca et Teri Radichel : superhéros de la sécurité

Ce n'est pas une compétition, mais les contributions de Tanya Janca et Teri Radichel à la conférence figuraient parmi mes préférées. Dix minutes après le début de leur tutoriel sur les évaluations de sécurité du cloud à faire soi-même, ils ont mis en lumière leur incroyable expérience, leurs qualifications et leur expertise, mais aussi leur véritable chaleur et leur désir de partager leurs connaissances et de soutenir la communauté des développeurs. Ensemble, ils ont présenté des actions réalistes et exécutables visant à garantir la sécurité des implémentations d'Azure, y compris des conseils pratiques sur la définition de politiques de sécurité et les mesures de moindre privilège.

Une recherche rapide sur Google vous indiquera tout ce que vous devez savoir sur leur engagement à soutenir les développeurs au niveau local, grâce à une multitude de ressources gratuites, à des opportunités de mentorat et à des entretiens visant à promouvoir le côté amusant et engageant de la sécurité logicielle. Ce sont des champions inspirants et essentiels de notre communauté ; s'ils prennent la parole lors de la prochaine conférence sur la sécurité à laquelle vous assisterez, vous seriez furieux de manquer leur session.

Des clients sur la grande scène

C'était formidable de voir un si grand nombre de nos clients non seulement présents, mais également propriétaires de la scène et partageant leurs immenses connaissances en matière de sécurité avec le public.

Nous avons réussi à attraper TelstraAndrew Bailey prononce une conférence importante intitulée « Ajouter le « SEC'to DevOps ». Sa riche expérience en tant qu'ingénieur logiciel senior, désormais focalisé sur la sécurité des applications et le codage sécurisé, était une excellente perspective à souligner. Il a donné des conseils complets sur la manière d'injecter de la sécurité à chaque étape du SDLC (y compris, bien entendu, dès le début en formant davantage de développeurs au codage sécurisé).

Ken Johnson fait partie de GitHubde l'équipe de sécurité, et j'ai été ravi de le voir rejoindre le panel d'experts à la fin de la conférence. À l'instar des autres panélistes, il était très heureux de répondre aux questions pressantes du public, y compris celles qui ne reçoivent pas nécessairement l'attention qu'elles méritent de la part des médias. En plus de plusieurs points de vue sur le secteur, il a fait parler au panel de l'importance du bien-être et de l'équilibre entre vie professionnelle et vie privée, ce qui est très important en cette ère d'épuisement des développeurs.

Je tiens à remercier chaleureusement Julian Berton et toute l'équipe de l'OWASP Melbourne pour cette nouvelle conférence incroyable. Rendez-vous l'année prochaine (avec d'autres autocollants).

J'ai récemment été interviewé pour Podcast Silver Bullet, animé par Gary McGraw, où j'ai discuté des avantages de l'industrie par rapport à la recherche universitaire, des raisons pour lesquelles il n'était pas anodin de créer une entreprise en Europe et de l'évolution future du secteur de la sécurité des applications.

Je n'ai jamais eu l'intention de créer une entreprise, mais je l'ai fait parce que je voyais trop d'entreprises aux prises avec le même problème ; écrire du code sécurisé représente un défi pour la plupart des développeurs. Toute une industrie se concentre sur la détection de problèmes de sécurité dans le code, et ces problèmes ne font que s'accumuler.

Il existe très peu de solutions qui visent réellement à aider efficacement les organisations et leur équipe de développement qui ont du mal à résoudre les problèmes détectés, et encore moins à essayer d'empêcher l'introduction de nouveaux problèmes dans le code. Les organisations prennent de plus en plus conscience de ce cercle vicieux et se rendent compte que leur équipe de développement doit être formée à l'écriture de code sécurisé dès le début et qu'elle doit être équipée des outils et des processus nécessaires pour les activer.

Si vous voulez en savoir plus sur la façon dont Gary McGraw et moi-même envisageons l'évolution de l'industrie, consultez le Podcast Silver Bullet!

Show 139 : Matias Madou discute de la formation au développement sécurisé et de la recherche sur les tests de sécurité logicielle

https://www.synopsys.com/software-integrity/resources/podcasts/show-139.html