攻撃対象領域が終わらない時代における防止

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.