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

Une version de cet article a été publiée dans SD Times. Il a été mis à jour et diffusé ici.

‍

Lorsque nous parlons de progrès, le progrès numérique est généralement au premier plan de la conversation. Nous voulons que tout soit meilleur, plus rapide, plus pratique, plus puissant, et nous voulons le faire pour moins d'argent, de temps et de risques. Dans la plupart des cas, ces objectifs « impossibles » sont finalement atteints ; cela peut prendre plusieurs années et plusieurs versions (et une équipe de développeurs qui pourrait lancer un coup d'État si on leur demande de changer de cap en matière de conception des fonctionnalités) encore une fois), mais chaque jour, du code change le monde.

Cependant, une grande expansion logicielle implique de grandes responsabilités, 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 mince affaire, et lorsque nous prenons en compte tous les aspects des risques liés aux logiciels, qu'il s'agisse du cloud, des systèmes intégrés dans les appareils et les véhicules, de notre infrastructure critique, sans oublier les API qui connectent tout cela, la surface d'attaque est sans frontières et incontrôlable.

Nous ne pouvons pas nous attendre à un moment 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 combler - mais nous pouvons, en tant qu'industrie, adopter une approche plus globale de la sécurité au niveau du code.

Voyons comment nous pouvons neutraliser cette surface d'attaque infinie à l'aide des outils à portée de main :

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

Une sécurité parfaite n'est pas durable, mais porter un bandeau sur les yeux et prétendre que tout est un ciel bleu ne l'est pas non plus. Nous savons déjà que les organisations expédient sciemment du code vulnérable, et il est clair qu'il s'agit d'un risque calculé en fonction du délai de commercialisation des nouvelles fonctionnalités et des nouveaux produits.

La rapidité de la sécurité constitue un défi, en particulier dans les domaines où DevSecOps n'est pas la méthodologie de développement standard. Cependant, il suffit de regarder les récents Exploit Log4Shell pour découvrir comment des problèmes de sécurité relativement minimes liés au code ont ouvert la voie à une attaque réussie, et pour constater que les conséquences de ces risques calculés sur la livraison de code de moindre qualité pourraient être bien 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 provoquées par des environnements de stockage cloud 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 entreprises.

En 2019, First American Financial Corp., société du Fortune 500. Je l'ai découvert à la dure. Une erreur d'authentification, relativement simple à corriger, a entraîné la divulgation de plus de 800 millions de dossiers, notamment des relevés bancaires, des contrats hypothécaires et des pièces d'identité avec photo. Leurs liens vers les documents ne nécessitaient aucune identification d'utilisateur ni aucune connexion, ce qui les rendait accessibles à toute personne utilisant 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 révélait un nouvel enregistrement de données.

Ce problème de sécurité a été identifié en interne avant d'être exposé dans les médias, toutefois, le fait de ne pas l'avoir correctement classé comme un problème de sécurité à haut risque et de ne pas l'avoir signalé à la haute direction pour qu'il y soit remédié d'urgence ont eu des répercussions qui se font encore sentir aujourd'hui.

Ce n'est pas pour rien que le contrôle d'accès cassé se trouve désormais tout en haut de Top 10 de l'OWASP: c'est aussi courant que la saleté, et les développeurs ont besoin de connaissances vérifiées en matière de sécurité et de compétences pratiques pour découvrir les meilleures pratiques en matière d'authentification et de privilèges dans leurs propres versions, en veillant à ce que des contrôles et des mesures soient en place pour protéger l'exposition des données sensibles.

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

Analysez votre programme de sécurité : quelle importance accordez-vous à la prévention ?

Il est logique qu'une grande partie d'un programme de sécurité soit dédié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é en premier lieu.

Bien sûr, il existe des outils de sécurité complets qui aident à découvrir les bogues problématiques, mais près de 50 % des entreprises ont admis avoir utilisé un code d'expédition dont elles savaient qu'il était vulnérable. Les contraintes de temps, la complexité des outils et le manque d'experts qualifiés pour répondre aux rapports contribuent à ce qui était essentiellement un risque calculé, mais le fait que le code doive être sécurisé dans le cloud, dans les applications, dans les fonctionnalités des API, les systèmes intégrés, les bibliothèques et un paysage technologique en constante évolution garantit que nous aurons toujours un retard par rapport à l'approche actuelle.

Les bogues de sécurité sont un problème d'origine humaine, et nous ne pouvons pas nous attendre à ce que les robots les corrigent à notre place. Si les compétences de votre cohorte de développement ne sont pas renforcées de manière efficace (il ne s'agit pas simplement d'un séminaire annuel, mais de modules pédagogiques appropriés), vous courez toujours le risque d'accepter un code de faible qualité en tant que standard, avec les risques de sécurité qui en découlent.

Avez-vous surestimé l'état 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é (ce n'est pas non plus un KPI dans de nombreux cas). Ils ne peuvent pas être les responsables de mauvaises pratiques de sécurité si on ne leur montre pas la meilleure voie à suivre ou si on ne leur dit pas que c'est une mesure de leur succès.

Trop souvent, toutefois, les organisations partent du principe que les conseils fournis ont été efficaces pour préparer l'équipe d'ingénierie à atténuer les risques de sécurité courants. En fonction de leur formation et de leur capacité à appliquer les meilleures pratiques de sécurité, il se peut qu'ils ne soient pas prêts à être la première ligne de défense souhaitable (et à empêcher les failles d'injection interminables qui obstruent les rapports de pentest).

L'idéal est que des parcours d'apprentissage de plus en plus complexes soient achevés et que les compétences qui en résultent soient 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 selon laquelle les développeurs sont pris en compte dès le début et correctement activé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.