La prévention à l'ère de la surface d'attaque sans fin
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.
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.
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émonstrationMatias 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.
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.
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.
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émonstrationMatias 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.
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
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échargerRessources pour vous aider à démarrer
Évaluation comparative des compétences en matière de sécurité : Rationalisation de la conception sécurisée dans l'entreprise
Le mouvement "Secure-by-Design" (conception sécurisée) est l'avenir du développement de logiciels sécurisés. Découvrez les éléments clés que les entreprises doivent garder à l'esprit lorsqu'elles envisagent une initiative de conception sécurisée.
DigitalOcean réduit sa dette de sécurité avec Secure Code Warrior
L'utilisation par DigitalOcean de la formation Secure Code Warrior a considérablement réduit la dette de sécurité, permettant aux équipes de se concentrer davantage sur l'innovation et la productivité. L'amélioration de la sécurité a renforcé la qualité des produits et l'avantage concurrentiel de l'entreprise. À l'avenir, le score de confiance SCW les aidera à améliorer leurs pratiques de sécurité et à continuer à stimuler l'innovation.
Ressources pour vous aider à démarrer
Sécurité réactive contre sécurité préventive : La prévention est un meilleur remède
L'idée d'apporter une sécurité préventive aux codes et systèmes existants en même temps qu'aux applications plus récentes peut sembler décourageante, mais une approche "Secure-by-Design", mise en œuvre en améliorant les compétences des développeurs, permet d'appliquer les meilleures pratiques de sécurité à ces systèmes. C'est la meilleure chance qu'ont de nombreuses organisations d'améliorer leur sécurité.
Les avantages de l'évaluation des compétences des développeurs en matière de sécurité
L'importance croissante accordée au code sécurisé et aux principes de conception sécurisée exige que les développeurs soient formés à la cybersécurité dès le début du cycle de développement durable, et que des outils tels que le Trust Score de Secure Code Warriorles aident à mesurer et à améliorer leurs progrès.
Assurer le succès des initiatives de conception sécurisée de l'entreprise
Notre dernier document de recherche, Benchmarking Security Skills : Streamlining Secure-by-Design in the Enterprise est le résultat d'une analyse approfondie d'initiatives réelles de conception sécurisée au niveau de l'entreprise, et de l'élaboration d'approches de meilleures pratiques basées sur des conclusions fondées sur des données.
Plongée en profondeur : Naviguer dans la vulnérabilité critique de CUPS dans les systèmes GNU-Linux
Découvrez les derniers défis de sécurité auxquels sont confrontés les utilisateurs de Linux en explorant les récentes vulnérabilités de haute sévérité dans le système d'impression commun d'UNIX (CUPS). Apprenez comment ces problèmes peuvent conduire à une potentielle exécution de code à distance (RCE) et ce que vous pouvez faire pour protéger vos systèmes.