Blog

La prévention à l'ère de la surface d'attaque sans fin

Matias Madou, Ph.D.
Publié le 09 septembre 2022

Une version de cet article a été publiée dans le SD Times. Elle a été mise à jour et publiée ici.

Lorsque nous parlons de progrès, c'est généralement le progrès numérique qui est au premier plan de la conversation. Nous voulons que tout soit meilleur, plus rapide, plus pratique, plus puissant, et nous voulons le faire en dépensant moins d'argent, en prenant moins de temps et en prenant moins de risques. La plupart du temps, ces objectifs "impossibles" finissent par être atteints ; cela peut prendre plusieurs années et de nombreuses versions (et une équipe de développeurs qui pourraient faire un coup d'État si on leur demandait de changer de vitesse sur la conception des fonctionnalités une fois de plus), mais chaque jour, le code est là, en train de changer le monde. 

Cependant, une grande expansion des logiciels s'accompagne d'une grande responsabilité, et la réalité est que nous ne sommes tout simplement pas prêts à y faire face du point de vue de la sécurité. Le développement de logiciels n'est plus une île, et lorsque nous prenons en compte tous les aspects des risques liés aux logiciels - le nuage, les systèmes embarqués dans les appareils et les véhicules, notre infrastructure critique, sans parler des API qui les relient tous - la surface d'attaque est sans frontières et incontrôlable. 

Nous ne pouvons pas nous attendre à une époque magique où chaque ligne de code est méticuleusement vérifiée par des experts en sécurité chevronnés - ce déficit de compétences n'est pas près de se résorber - mais nous pouvons, en tant qu'industrie, adopter une approche plus holistique de la sécurité au niveau du code.

Voyons comment nous pouvons maîtriser cette surface d'attaque infinie avec les outils dont nous disposons :

Soyez réaliste quant au niveau de risque commercial (et à ce que vous êtes prêt à accepter).

La sécurité parfaite n'est pas viable, mais il ne faut pas non plus se mettre un bandeau sur les yeux et prétendre que tout va pour le mieux. Nous savons déjà que des organisations livrent sciemment du code vulnérable, et il est clair qu'il s'agit d'un risque calculé en fonction du délai de mise sur le marché de nouvelles fonctionnalités et de nouveaux produits. 

La sécurité à grande vitesse est un défi, en particulier dans les endroits où DevSecOps n'est pas la méthodologie de développement standard. Cependant, il suffit de regarder le récent exploit Log4Shell pour découvrir comment des problèmes de sécurité relativement mineurs dans le code ont ouvert des opportunités pour une attaque réussie, et voir que les conséquences de ces risques calculés pour l'envoi de code de moindre qualité pourraient être beaucoup plus importantes que prévu.

Soyez à l'aise avec le fait d'être un maniaque du contrôle (d'accès)

Un nombre alarmant de violations de données coûteuses sont causées par des environnements de stockage en nuage mal configurés, et le risque d'exposition de données sensibles résultant d'erreurs de contrôle d'accès continue de hanter les équipes de sécurité de la plupart des organisations. 

En 2019, la société First American Financial Corp., classée au Fortune 500, l'a appris à ses dépens. Une erreur d'authentification - relativement simple à corriger - a conduit à l'exposition de plus de 800 millions de documents, notamment des relevés bancaires, des contrats hypothécaires et des photos d'identité. Les liens vers ces documents ne nécessitaient aucune identification ou connexion de la part de l'utilisateur, ce qui les rendait accessibles à toute personne disposant d'un navigateur web. Pire encore, ils étaient enregistrés avec des numéros séquentiels, ce qui signifie qu'un simple changement de numéro dans le lien exposait un nouvel enregistrement de données. 

Ce problème de sécurité a été identifié en interne avant d'être révélé par les médias, mais le fait de ne pas l'avoir classé correctement comme un problème de sécurité à haut risque et de ne pas l'avoir signalé à la direction pour qu'elle y remédie d'urgence a entraîné des retombées qui se font encore sentir aujourd'hui.

Ce n'est pas pour rien que le contrôle d'accès défaillant figure désormais en tête du Top 10 de l'OWASP: il est aussi courant que la saleté, et les développeurs ont besoin d'une sensibilisation à la sécurité vérifiée et de compétences pratiques pour appliquer les meilleures pratiques en matière d'authentification et de privilèges dans leurs propres créations, en veillant à ce que des contrôles et des mesures soient en place pour protéger l'exposition aux données sensibles. 

La nature des API les rend particulièrement pertinentes et délicates ; elles sont très bavardes avec d'autres applications de par leur conception, et les équipes de développement doivent avoir une visibilité sur tous les points d'accès potentiels. Après tout, elles ne peuvent pas prendre en considération des variables et des cas d'utilisation inconnus dans leur quête d'un logiciel plus sûr.

Analysez votre programme de sécurité : quelle est l'importance accordée à la prévention ?

Il est logique qu'une grande partie d'un programme de sécurité soit consacrée à la réponse et à la réaction aux incidents, mais de nombreuses organisations ne parviennent pas à minimiser les risques en n'utilisant pas toutes les ressources disponibles pour prévenir un incident de sécurité dès le départ.

Bien sûr, il existe des piles complètes d'outils de sécurité qui aident à découvrir les bogues problématiques, mais près de 50 % des entreprises ont admis avoir expédié du code qu'elles savaient vulnérable. Les contraintes de temps, la complexité des outils et le manque d'experts formés pour répondre aux rapports contribuent tous à ce qui a été essentiellement un risque calculé, mais le fait que le code doive être sécurisé dans le nuage, dans les applications, dans les fonctionnalités API, dans les systèmes intégrés, dans les bibliothèques et dans un paysage technologique de plus en plus large, garantit que nous aurons toujours un pas de retard avec l'approche actuelle.

Les bogues de sécurité sont un problème d'origine humaine, et nous ne pouvons pas attendre des robots qu'ils fassent toutes les corrections à notre place. Si votre cohorte de développeurs ne bénéficie pas d'une formation continue efficace - pas seulement un séminaire annuel, mais des modules de formation adéquats - vous risquez toujours d'accepter un code de mauvaise qualité comme norme, avec les risques de sécurité qui en découlent. 

Avez-vous surestimé le niveau de préparation de vos développeurs ?

Les développeurs sont rarement évalués sur leurs capacités de codage sécurisé, et ce n'est pas leur priorité (ni un indicateur de performance dans de nombreux cas). Ils ne peuvent pas être les boucs émissaires de mauvaises pratiques de sécurité si on ne leur montre pas une meilleure voie ou si on ne leur dit pas que c'est une mesure de leur succès. 

Trop souvent, cependant, les organisations partent du principe que les conseils fournis ont été efficaces pour préparer l'équipe d'ingénieurs à atténuer les risques de sécurité courants. En fonction de la formation et de leur sensibilisation à l'application des meilleures pratiques de sécurité, ils peuvent ne pas être préparés à constituer cette première ligne de défense souhaitable (et à empêcher d'innombrables failles d'injection d'encombrer les rapports de pentest). 

Dans l'idéal, des parcours d'apprentissage de complexité croissante sont réalisés, et les compétences qui en résultent sont vérifiées pour s'assurer qu'elles fonctionnent réellement pour le développeur dans le monde réel. Cependant, cela nécessite une norme culturelle où les développeurs sont pris en compte dès le début et correctement habilités. Si, en tant qu'industrie, nous partons dans la nature pour défendre ce vaste paysage de code que nous avons créé nous-mêmes, nous aurons besoin de toute l'aide possible... et il y en a plus devant nous que nous ne le pensons.

Voir la ressource
Voir la ressource

Le développement de logiciels n'est plus une île, et lorsque nous prenons en compte tous les aspects des risques liés aux logiciels - tout ce qui va du nuage aux systèmes embarqués dans les appareils et les véhicules, en passant par notre infrastructure critique, sans oublier les API qui les relient tous - la surface d'attaque est sans frontières et incontrôlable.

Vous souhaitez en savoir plus ?

Matias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu son doctorat en sécurité des applications à l'université de Gand, en se concentrant sur les solutions d'analyse statique. Il a ensuite rejoint Fortify aux États-Unis, où il s'est rendu compte qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. C'est ce qui l'a incité à développer des produits qui aident les développeurs, allègent le fardeau de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de l'équipe Awesome, il aime être sur scène pour présenter des conférences, notamment RSA Conference, BlackHat et DefCon.

Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.

Réservez une démonstration
Partager sur :
Auteur
Matias Madou, Ph.D.
Publié le 09 septembre 2022

Matias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu son doctorat en sécurité des applications à l'université de Gand, en se concentrant sur les solutions d'analyse statique. Il a ensuite rejoint Fortify aux États-Unis, où il s'est rendu compte qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. C'est ce qui l'a incité à développer des produits qui aident les développeurs, allègent le fardeau de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de l'équipe Awesome, il aime être sur scène pour présenter des conférences, notamment RSA Conference, BlackHat et DefCon.

Matias est un chercheur et un développeur qui possède plus de 15 ans d'expérience pratique dans le domaine de la sécurité des logiciels. Il a développé des solutions pour des entreprises telles que Fortify Software et sa propre entreprise Sensei Security. Au cours de sa carrière, Matias a dirigé de nombreux projets de recherche sur la sécurité des applications qui ont débouché sur des produits commerciaux et peut se targuer d'avoir déposé plus de 10 brevets. Lorsqu'il n'est pas à son bureau, Matias a été instructeur pour des formations avancées en matière de sécurité des applications ( courses ) et intervient régulièrement lors de conférences mondiales telles que RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec et BruCon.

Matias est titulaire d'un doctorat en ingénierie informatique de l'Université de Gand, où il a étudié la sécurité des applications par le biais de l'obscurcissement des programmes afin de dissimuler le fonctionnement interne d'une application.

Partager sur :

Une version de cet article a été publiée dans le SD Times. Elle a été mise à jour et publiée ici.

Lorsque nous parlons de progrès, c'est généralement le progrès numérique qui est au premier plan de la conversation. Nous voulons que tout soit meilleur, plus rapide, plus pratique, plus puissant, et nous voulons le faire en dépensant moins d'argent, en prenant moins de temps et en prenant moins de risques. La plupart du temps, ces objectifs "impossibles" finissent par être atteints ; cela peut prendre plusieurs années et de nombreuses versions (et une équipe de développeurs qui pourraient faire un coup d'État si on leur demandait de changer de vitesse sur la conception des fonctionnalités une fois de plus), mais chaque jour, le code est là, en train de changer le monde. 

Cependant, une grande expansion des logiciels s'accompagne d'une grande responsabilité, et la réalité est que nous ne sommes tout simplement pas prêts à y faire face du point de vue de la sécurité. Le développement de logiciels n'est plus une île, et lorsque nous prenons en compte tous les aspects des risques liés aux logiciels - le nuage, les systèmes embarqués dans les appareils et les véhicules, notre infrastructure critique, sans parler des API qui les relient tous - la surface d'attaque est sans frontières et incontrôlable. 

Nous ne pouvons pas nous attendre à une époque magique où chaque ligne de code est méticuleusement vérifiée par des experts en sécurité chevronnés - ce déficit de compétences n'est pas près de se résorber - mais nous pouvons, en tant qu'industrie, adopter une approche plus holistique de la sécurité au niveau du code.

Voyons comment nous pouvons maîtriser cette surface d'attaque infinie avec les outils dont nous disposons :

Soyez réaliste quant au niveau de risque commercial (et à ce que vous êtes prêt à accepter).

La sécurité parfaite n'est pas viable, mais il ne faut pas non plus se mettre un bandeau sur les yeux et prétendre que tout va pour le mieux. Nous savons déjà que des organisations livrent sciemment du code vulnérable, et il est clair qu'il s'agit d'un risque calculé en fonction du délai de mise sur le marché de nouvelles fonctionnalités et de nouveaux produits. 

La sécurité à grande vitesse est un défi, en particulier dans les endroits où DevSecOps n'est pas la méthodologie de développement standard. Cependant, il suffit de regarder le récent exploit Log4Shell pour découvrir comment des problèmes de sécurité relativement mineurs dans le code ont ouvert des opportunités pour une attaque réussie, et voir que les conséquences de ces risques calculés pour l'envoi de code de moindre qualité pourraient être beaucoup plus importantes que prévu.

Soyez à l'aise avec le fait d'être un maniaque du contrôle (d'accès)

Un nombre alarmant de violations de données coûteuses sont causées par des environnements de stockage en nuage mal configurés, et le risque d'exposition de données sensibles résultant d'erreurs de contrôle d'accès continue de hanter les équipes de sécurité de la plupart des organisations. 

En 2019, la société First American Financial Corp., classée au Fortune 500, l'a appris à ses dépens. Une erreur d'authentification - relativement simple à corriger - a conduit à l'exposition de plus de 800 millions de documents, notamment des relevés bancaires, des contrats hypothécaires et des photos d'identité. Les liens vers ces documents ne nécessitaient aucune identification ou connexion de la part de l'utilisateur, ce qui les rendait accessibles à toute personne disposant d'un navigateur web. Pire encore, ils étaient enregistrés avec des numéros séquentiels, ce qui signifie qu'un simple changement de numéro dans le lien exposait un nouvel enregistrement de données. 

Ce problème de sécurité a été identifié en interne avant d'être révélé par les médias, mais le fait de ne pas l'avoir classé correctement comme un problème de sécurité à haut risque et de ne pas l'avoir signalé à la direction pour qu'elle y remédie d'urgence a entraîné des retombées qui se font encore sentir aujourd'hui.

Ce n'est pas pour rien que le contrôle d'accès défaillant figure désormais en tête du Top 10 de l'OWASP: il est aussi courant que la saleté, et les développeurs ont besoin d'une sensibilisation à la sécurité vérifiée et de compétences pratiques pour appliquer les meilleures pratiques en matière d'authentification et de privilèges dans leurs propres créations, en veillant à ce que des contrôles et des mesures soient en place pour protéger l'exposition aux données sensibles. 

La nature des API les rend particulièrement pertinentes et délicates ; elles sont très bavardes avec d'autres applications de par leur conception, et les équipes de développement doivent avoir une visibilité sur tous les points d'accès potentiels. Après tout, elles ne peuvent pas prendre en considération des variables et des cas d'utilisation inconnus dans leur quête d'un logiciel plus sûr.

Analysez votre programme de sécurité : quelle est l'importance accordée à la prévention ?

Il est logique qu'une grande partie d'un programme de sécurité soit consacrée à la réponse et à la réaction aux incidents, mais de nombreuses organisations ne parviennent pas à minimiser les risques en n'utilisant pas toutes les ressources disponibles pour prévenir un incident de sécurité dès le départ.

Bien sûr, il existe des piles complètes d'outils de sécurité qui aident à découvrir les bogues problématiques, mais près de 50 % des entreprises ont admis avoir expédié du code qu'elles savaient vulnérable. Les contraintes de temps, la complexité des outils et le manque d'experts formés pour répondre aux rapports contribuent tous à ce qui a été essentiellement un risque calculé, mais le fait que le code doive être sécurisé dans le nuage, dans les applications, dans les fonctionnalités API, dans les systèmes intégrés, dans les bibliothèques et dans un paysage technologique de plus en plus large, garantit que nous aurons toujours un pas de retard avec l'approche actuelle.

Les bogues de sécurité sont un problème d'origine humaine, et nous ne pouvons pas attendre des robots qu'ils fassent toutes les corrections à notre place. Si votre cohorte de développeurs ne bénéficie pas d'une formation continue efficace - pas seulement un séminaire annuel, mais des modules de formation adéquats - vous risquez toujours d'accepter un code de mauvaise qualité comme norme, avec les risques de sécurité qui en découlent. 

Avez-vous surestimé le niveau de préparation de vos développeurs ?

Les développeurs sont rarement évalués sur leurs capacités de codage sécurisé, et ce n'est pas leur priorité (ni un indicateur de performance dans de nombreux cas). Ils ne peuvent pas être les boucs émissaires de mauvaises pratiques de sécurité si on ne leur montre pas une meilleure voie ou si on ne leur dit pas que c'est une mesure de leur succès. 

Trop souvent, cependant, les organisations partent du principe que les conseils fournis ont été efficaces pour préparer l'équipe d'ingénieurs à atténuer les risques de sécurité courants. En fonction de la formation et de leur sensibilisation à l'application des meilleures pratiques de sécurité, ils peuvent ne pas être préparés à constituer cette première ligne de défense souhaitable (et à empêcher d'innombrables failles d'injection d'encombrer les rapports de pentest). 

Dans l'idéal, des parcours d'apprentissage de complexité croissante sont réalisés, et les compétences qui en résultent sont vérifiées pour s'assurer qu'elles fonctionnent réellement pour le développeur dans le monde réel. Cependant, cela nécessite une norme culturelle où les développeurs sont pris en compte dès le début et correctement habilités. Si, en tant qu'industrie, nous partons dans la nature pour défendre ce vaste paysage de code que nous avons créé nous-mêmes, nous aurons besoin de toute l'aide possible... et il y en a plus devant nous que nous ne le pensons.

Voir la ressource
Voir la ressource

Remplissez le formulaire ci-dessous pour télécharger le rapport

Nous aimerions que vous nous autorisiez à vous envoyer des informations sur nos produits et/ou sur des sujets liés au codage sécurisé. Nous traiterons toujours vos données personnelles avec le plus grand soin et ne les vendrons jamais à d'autres entreprises à des fins de marketing.

Soumettre
Pour soumettre le formulaire, veuillez activer les cookies "Analytics". N'hésitez pas à les désactiver à nouveau une fois que vous aurez terminé.

Une version de cet article a été publiée dans le SD Times. Elle a été mise à jour et publiée ici.

Lorsque nous parlons de progrès, c'est généralement le progrès numérique qui est au premier plan de la conversation. Nous voulons que tout soit meilleur, plus rapide, plus pratique, plus puissant, et nous voulons le faire en dépensant moins d'argent, en prenant moins de temps et en prenant moins de risques. La plupart du temps, ces objectifs "impossibles" finissent par être atteints ; cela peut prendre plusieurs années et de nombreuses versions (et une équipe de développeurs qui pourraient faire un coup d'État si on leur demandait de changer de vitesse sur la conception des fonctionnalités une fois de plus), mais chaque jour, le code est là, en train de changer le monde. 

Cependant, une grande expansion des logiciels s'accompagne d'une grande responsabilité, et la réalité est que nous ne sommes tout simplement pas prêts à y faire face du point de vue de la sécurité. Le développement de logiciels n'est plus une île, et lorsque nous prenons en compte tous les aspects des risques liés aux logiciels - le nuage, les systèmes embarqués dans les appareils et les véhicules, notre infrastructure critique, sans parler des API qui les relient tous - la surface d'attaque est sans frontières et incontrôlable. 

Nous ne pouvons pas nous attendre à une époque magique où chaque ligne de code est méticuleusement vérifiée par des experts en sécurité chevronnés - ce déficit de compétences n'est pas près de se résorber - mais nous pouvons, en tant qu'industrie, adopter une approche plus holistique de la sécurité au niveau du code.

Voyons comment nous pouvons maîtriser cette surface d'attaque infinie avec les outils dont nous disposons :

Soyez réaliste quant au niveau de risque commercial (et à ce que vous êtes prêt à accepter).

La sécurité parfaite n'est pas viable, mais il ne faut pas non plus se mettre un bandeau sur les yeux et prétendre que tout va pour le mieux. Nous savons déjà que des organisations livrent sciemment du code vulnérable, et il est clair qu'il s'agit d'un risque calculé en fonction du délai de mise sur le marché de nouvelles fonctionnalités et de nouveaux produits. 

La sécurité à grande vitesse est un défi, en particulier dans les endroits où DevSecOps n'est pas la méthodologie de développement standard. Cependant, il suffit de regarder le récent exploit Log4Shell pour découvrir comment des problèmes de sécurité relativement mineurs dans le code ont ouvert des opportunités pour une attaque réussie, et voir que les conséquences de ces risques calculés pour l'envoi de code de moindre qualité pourraient être beaucoup plus importantes que prévu.

Soyez à l'aise avec le fait d'être un maniaque du contrôle (d'accès)

Un nombre alarmant de violations de données coûteuses sont causées par des environnements de stockage en nuage mal configurés, et le risque d'exposition de données sensibles résultant d'erreurs de contrôle d'accès continue de hanter les équipes de sécurité de la plupart des organisations. 

En 2019, la société First American Financial Corp., classée au Fortune 500, l'a appris à ses dépens. Une erreur d'authentification - relativement simple à corriger - a conduit à l'exposition de plus de 800 millions de documents, notamment des relevés bancaires, des contrats hypothécaires et des photos d'identité. Les liens vers ces documents ne nécessitaient aucune identification ou connexion de la part de l'utilisateur, ce qui les rendait accessibles à toute personne disposant d'un navigateur web. Pire encore, ils étaient enregistrés avec des numéros séquentiels, ce qui signifie qu'un simple changement de numéro dans le lien exposait un nouvel enregistrement de données. 

Ce problème de sécurité a été identifié en interne avant d'être révélé par les médias, mais le fait de ne pas l'avoir classé correctement comme un problème de sécurité à haut risque et de ne pas l'avoir signalé à la direction pour qu'elle y remédie d'urgence a entraîné des retombées qui se font encore sentir aujourd'hui.

Ce n'est pas pour rien que le contrôle d'accès défaillant figure désormais en tête du Top 10 de l'OWASP: il est aussi courant que la saleté, et les développeurs ont besoin d'une sensibilisation à la sécurité vérifiée et de compétences pratiques pour appliquer les meilleures pratiques en matière d'authentification et de privilèges dans leurs propres créations, en veillant à ce que des contrôles et des mesures soient en place pour protéger l'exposition aux données sensibles. 

La nature des API les rend particulièrement pertinentes et délicates ; elles sont très bavardes avec d'autres applications de par leur conception, et les équipes de développement doivent avoir une visibilité sur tous les points d'accès potentiels. Après tout, elles ne peuvent pas prendre en considération des variables et des cas d'utilisation inconnus dans leur quête d'un logiciel plus sûr.

Analysez votre programme de sécurité : quelle est l'importance accordée à la prévention ?

Il est logique qu'une grande partie d'un programme de sécurité soit consacrée à la réponse et à la réaction aux incidents, mais de nombreuses organisations ne parviennent pas à minimiser les risques en n'utilisant pas toutes les ressources disponibles pour prévenir un incident de sécurité dès le départ.

Bien sûr, il existe des piles complètes d'outils de sécurité qui aident à découvrir les bogues problématiques, mais près de 50 % des entreprises ont admis avoir expédié du code qu'elles savaient vulnérable. Les contraintes de temps, la complexité des outils et le manque d'experts formés pour répondre aux rapports contribuent tous à ce qui a été essentiellement un risque calculé, mais le fait que le code doive être sécurisé dans le nuage, dans les applications, dans les fonctionnalités API, dans les systèmes intégrés, dans les bibliothèques et dans un paysage technologique de plus en plus large, garantit que nous aurons toujours un pas de retard avec l'approche actuelle.

Les bogues de sécurité sont un problème d'origine humaine, et nous ne pouvons pas attendre des robots qu'ils fassent toutes les corrections à notre place. Si votre cohorte de développeurs ne bénéficie pas d'une formation continue efficace - pas seulement un séminaire annuel, mais des modules de formation adéquats - vous risquez toujours d'accepter un code de mauvaise qualité comme norme, avec les risques de sécurité qui en découlent. 

Avez-vous surestimé le niveau de préparation de vos développeurs ?

Les développeurs sont rarement évalués sur leurs capacités de codage sécurisé, et ce n'est pas leur priorité (ni un indicateur de performance dans de nombreux cas). Ils ne peuvent pas être les boucs émissaires de mauvaises pratiques de sécurité si on ne leur montre pas une meilleure voie ou si on ne leur dit pas que c'est une mesure de leur succès. 

Trop souvent, cependant, les organisations partent du principe que les conseils fournis ont été efficaces pour préparer l'équipe d'ingénieurs à atténuer les risques de sécurité courants. En fonction de la formation et de leur sensibilisation à l'application des meilleures pratiques de sécurité, ils peuvent ne pas être préparés à constituer cette première ligne de défense souhaitable (et à empêcher d'innombrables failles d'injection d'encombrer les rapports de pentest). 

Dans l'idéal, des parcours d'apprentissage de complexité croissante sont réalisés, et les compétences qui en résultent sont vérifiées pour s'assurer qu'elles fonctionnent réellement pour le développeur dans le monde réel. Cependant, cela nécessite une norme culturelle où les développeurs sont pris en compte dès le début et correctement habilités. Si, en tant qu'industrie, nous partons dans la nature pour défendre ce vaste paysage de code que nous avons créé nous-mêmes, nous aurons besoin de toute l'aide possible... et il y en a plus devant nous que nous ne le pensons.

Accès aux ressources

Cliquez sur le lien ci-dessous et téléchargez le PDF de cette ressource.

Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.

Voir le rapportRéservez une démonstration
Télécharger le PDF
Voir la ressource
Partager sur :
Vous souhaitez en savoir plus ?

Partager sur :
Auteur
Matias Madou, Ph.D.
Publié le 09 septembre 2022

Matias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu son doctorat en sécurité des applications à l'université de Gand, en se concentrant sur les solutions d'analyse statique. Il a ensuite rejoint Fortify aux États-Unis, où il s'est rendu compte qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. C'est ce qui l'a incité à développer des produits qui aident les développeurs, allègent le fardeau de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de l'équipe Awesome, il aime être sur scène pour présenter des conférences, notamment RSA Conference, BlackHat et DefCon.

Matias est un chercheur et un développeur qui possède plus de 15 ans d'expérience pratique dans le domaine de la sécurité des logiciels. Il a développé des solutions pour des entreprises telles que Fortify Software et sa propre entreprise Sensei Security. Au cours de sa carrière, Matias a dirigé de nombreux projets de recherche sur la sécurité des applications qui ont débouché sur des produits commerciaux et peut se targuer d'avoir déposé plus de 10 brevets. Lorsqu'il n'est pas à son bureau, Matias a été instructeur pour des formations avancées en matière de sécurité des applications ( courses ) et intervient régulièrement lors de conférences mondiales telles que RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec et BruCon.

Matias est titulaire d'un doctorat en ingénierie informatique de l'Université de Gand, où il a étudié la sécurité des applications par le biais de l'obscurcissement des programmes afin de dissimuler le fonctionnement interne d'une application.

Partager sur :

Une version de cet article a été publiée dans le SD Times. Elle a été mise à jour et publiée ici.

Lorsque nous parlons de progrès, c'est généralement le progrès numérique qui est au premier plan de la conversation. Nous voulons que tout soit meilleur, plus rapide, plus pratique, plus puissant, et nous voulons le faire en dépensant moins d'argent, en prenant moins de temps et en prenant moins de risques. La plupart du temps, ces objectifs "impossibles" finissent par être atteints ; cela peut prendre plusieurs années et de nombreuses versions (et une équipe de développeurs qui pourraient faire un coup d'État si on leur demandait de changer de vitesse sur la conception des fonctionnalités une fois de plus), mais chaque jour, le code est là, en train de changer le monde. 

Cependant, une grande expansion des logiciels s'accompagne d'une grande responsabilité, et la réalité est que nous ne sommes tout simplement pas prêts à y faire face du point de vue de la sécurité. Le développement de logiciels n'est plus une île, et lorsque nous prenons en compte tous les aspects des risques liés aux logiciels - le nuage, les systèmes embarqués dans les appareils et les véhicules, notre infrastructure critique, sans parler des API qui les relient tous - la surface d'attaque est sans frontières et incontrôlable. 

Nous ne pouvons pas nous attendre à une époque magique où chaque ligne de code est méticuleusement vérifiée par des experts en sécurité chevronnés - ce déficit de compétences n'est pas près de se résorber - mais nous pouvons, en tant qu'industrie, adopter une approche plus holistique de la sécurité au niveau du code.

Voyons comment nous pouvons maîtriser cette surface d'attaque infinie avec les outils dont nous disposons :

Soyez réaliste quant au niveau de risque commercial (et à ce que vous êtes prêt à accepter).

La sécurité parfaite n'est pas viable, mais il ne faut pas non plus se mettre un bandeau sur les yeux et prétendre que tout va pour le mieux. Nous savons déjà que des organisations livrent sciemment du code vulnérable, et il est clair qu'il s'agit d'un risque calculé en fonction du délai de mise sur le marché de nouvelles fonctionnalités et de nouveaux produits. 

La sécurité à grande vitesse est un défi, en particulier dans les endroits où DevSecOps n'est pas la méthodologie de développement standard. Cependant, il suffit de regarder le récent exploit Log4Shell pour découvrir comment des problèmes de sécurité relativement mineurs dans le code ont ouvert des opportunités pour une attaque réussie, et voir que les conséquences de ces risques calculés pour l'envoi de code de moindre qualité pourraient être beaucoup plus importantes que prévu.

Soyez à l'aise avec le fait d'être un maniaque du contrôle (d'accès)

Un nombre alarmant de violations de données coûteuses sont causées par des environnements de stockage en nuage mal configurés, et le risque d'exposition de données sensibles résultant d'erreurs de contrôle d'accès continue de hanter les équipes de sécurité de la plupart des organisations. 

En 2019, la société First American Financial Corp., classée au Fortune 500, l'a appris à ses dépens. Une erreur d'authentification - relativement simple à corriger - a conduit à l'exposition de plus de 800 millions de documents, notamment des relevés bancaires, des contrats hypothécaires et des photos d'identité. Les liens vers ces documents ne nécessitaient aucune identification ou connexion de la part de l'utilisateur, ce qui les rendait accessibles à toute personne disposant d'un navigateur web. Pire encore, ils étaient enregistrés avec des numéros séquentiels, ce qui signifie qu'un simple changement de numéro dans le lien exposait un nouvel enregistrement de données. 

Ce problème de sécurité a été identifié en interne avant d'être révélé par les médias, mais le fait de ne pas l'avoir classé correctement comme un problème de sécurité à haut risque et de ne pas l'avoir signalé à la direction pour qu'elle y remédie d'urgence a entraîné des retombées qui se font encore sentir aujourd'hui.

Ce n'est pas pour rien que le contrôle d'accès défaillant figure désormais en tête du Top 10 de l'OWASP: il est aussi courant que la saleté, et les développeurs ont besoin d'une sensibilisation à la sécurité vérifiée et de compétences pratiques pour appliquer les meilleures pratiques en matière d'authentification et de privilèges dans leurs propres créations, en veillant à ce que des contrôles et des mesures soient en place pour protéger l'exposition aux données sensibles. 

La nature des API les rend particulièrement pertinentes et délicates ; elles sont très bavardes avec d'autres applications de par leur conception, et les équipes de développement doivent avoir une visibilité sur tous les points d'accès potentiels. Après tout, elles ne peuvent pas prendre en considération des variables et des cas d'utilisation inconnus dans leur quête d'un logiciel plus sûr.

Analysez votre programme de sécurité : quelle est l'importance accordée à la prévention ?

Il est logique qu'une grande partie d'un programme de sécurité soit consacrée à la réponse et à la réaction aux incidents, mais de nombreuses organisations ne parviennent pas à minimiser les risques en n'utilisant pas toutes les ressources disponibles pour prévenir un incident de sécurité dès le départ.

Bien sûr, il existe des piles complètes d'outils de sécurité qui aident à découvrir les bogues problématiques, mais près de 50 % des entreprises ont admis avoir expédié du code qu'elles savaient vulnérable. Les contraintes de temps, la complexité des outils et le manque d'experts formés pour répondre aux rapports contribuent tous à ce qui a été essentiellement un risque calculé, mais le fait que le code doive être sécurisé dans le nuage, dans les applications, dans les fonctionnalités API, dans les systèmes intégrés, dans les bibliothèques et dans un paysage technologique de plus en plus large, garantit que nous aurons toujours un pas de retard avec l'approche actuelle.

Les bogues de sécurité sont un problème d'origine humaine, et nous ne pouvons pas attendre des robots qu'ils fassent toutes les corrections à notre place. Si votre cohorte de développeurs ne bénéficie pas d'une formation continue efficace - pas seulement un séminaire annuel, mais des modules de formation adéquats - vous risquez toujours d'accepter un code de mauvaise qualité comme norme, avec les risques de sécurité qui en découlent. 

Avez-vous surestimé le niveau de préparation de vos développeurs ?

Les développeurs sont rarement évalués sur leurs capacités de codage sécurisé, et ce n'est pas leur priorité (ni un indicateur de performance dans de nombreux cas). Ils ne peuvent pas être les boucs émissaires de mauvaises pratiques de sécurité si on ne leur montre pas une meilleure voie ou si on ne leur dit pas que c'est une mesure de leur succès. 

Trop souvent, cependant, les organisations partent du principe que les conseils fournis ont été efficaces pour préparer l'équipe d'ingénieurs à atténuer les risques de sécurité courants. En fonction de la formation et de leur sensibilisation à l'application des meilleures pratiques de sécurité, ils peuvent ne pas être préparés à constituer cette première ligne de défense souhaitable (et à empêcher d'innombrables failles d'injection d'encombrer les rapports de pentest). 

Dans l'idéal, des parcours d'apprentissage de complexité croissante sont réalisés, et les compétences qui en résultent sont vérifiées pour s'assurer qu'elles fonctionnent réellement pour le développeur dans le monde réel. Cependant, cela nécessite une norme culturelle où les développeurs sont pris en compte dès le début et correctement habilités. Si, en tant qu'industrie, nous partons dans la nature pour défendre ce vaste paysage de code que nous avons créé nous-mêmes, nous aurons besoin de toute l'aide possible... et il y en a plus devant nous que nous ne le pensons.

Table des matières

Télécharger le PDF
Voir la ressource
Vous souhaitez en savoir plus ?

Matias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu son doctorat en sécurité des applications à l'université de Gand, en se concentrant sur les solutions d'analyse statique. Il a ensuite rejoint Fortify aux États-Unis, où il s'est rendu compte qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. C'est ce qui l'a incité à développer des produits qui aident les développeurs, allègent le fardeau de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de l'équipe Awesome, il aime être sur scène pour présenter des conférences, notamment RSA Conference, BlackHat et DefCon.

Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.

Réservez une démonstrationTélécharger
Partager sur :
Centre de ressources

Ressources pour vous aider à démarrer

Plus d'articles
Centre de ressources

Ressources pour vous aider à démarrer

Plus d'articles