Tribune d'Elimane Prud’hom (Sales Director, SALT)

Les développeurs ont pour mission de créer des applications modernes plus incroyables les unes que les autres – du streaming vidéo sur mobile aux services de livraison de repas et de transport – et ce, dans un délai toujours plus court pour permettre à leur entreprise de prendre une longueur d’avance sur la concurrence. Face à ces exigences, les développeurs doivent adopter la méthode agile et les techniques DevOps pour tenir la cadence et accélérer les cycles de développement.

Ce nouveau paradigme a mis en branle un « décalage à gauche » de la sécurité, ou « Shift Left » : une approche qui consiste à intégrer les exigences de sécurité dès les premiers stades d’un projet. Les objectifs métier sont simples : raccourcir les délais de développement, employer moins de ressources humaines et réduire les coûts.

Shift Left : Une approche efficace, mais pas dans toutes les situations

Avant le déploiement d’une technologie donnée, les entreprises peuvent instaurer des directives et des paramètres de sécurité à respecter dès les premières phases de développement. C’est dans le cas des technologies nouvelles et émergentes que les stratégies Shift Left offrent la plus forte valeur ajoutée.

Les équipes n’ont pas à revenir en arrière pour ajouter des fonctionnalités de sécurité puisque ces technologies n’ont pas encore été intégrées dans l’environnement général. La sécurité des conteneurs offre un bon exemple d’une approche « shift left » efficace, un modèle qui a généré une valeur considérable pour les entreprises.

Néanmoins, les stratégies Shift Left perdent très vite tout leur intérêt lorsqu’elles sont appliquées aux technologies déjà bien en place, car cette approche engendre de nombreuses failles de sécurité qui accroissent l’exposition au risque des entreprises.

Menace sur les actifs opérationnels

L’approche Shift Left sert uniquement à identifier les lacunes de sécurité au cours du développement. Elle ne protège pas les actifs déjà opérationnels, c’est pourquoi la surveillance en production et la prise de mesures de protection demeureront toujours indispensables.

Prenons l’exemple des interfaces de programmation des applications (API). Utilisées depuis de nombreuses années, les API ont connu un essor fulgurant avec la multiplication des services dématérialisés et des applications en ligne, car elles permettent un échange de données instantané entre plusieurs plateformes.

Aujourd’hui, une entreprise lambda exécute des centaines, voire des milliers d’API dans son environnement de production. Le développement des API s’est tellement accéléré ces dernières années que la plupart des entreprises ne savent même plus combien elles en exploitent, et ne sont donc pas en mesure de les protéger.

Meilleur ratio effort/valeur

D’après une récente étude du Ponemon Institute, intitulée Costs and Consequences in Gaps in Vulnerability Response, la majorité des entreprises (62 %) n’ont pas conscience des vulnérabilités susceptibles d’aboutir à une violation de données. En outre, 60 % des victimes parmi les sondés ont déclaré que la violation en question était due à une vulnérabilité connue à laquelle le correctif de sécurité n’avait simplement pas encore été appliqué.

Les chercheurs ont également constaté un allongement considérable des délais de correction des vulnérabilités, surtout dans les cas les plus graves. Ce rapport pointe en effet une augmentation supérieure à 25 % du temps nécessaire pour corriger ce type de vulnérabilité, soit 246 jours au lieu de 194.

Peu d’entreprises pourraient survivre avec un tel calendrier. Pour réduire le risque en amont, les entreprises doivent d’abord suivre l’approche Shift Right, avant d’opérer un décalage à gauche, de façon à réduire les risques dans les plus brefs délais et de la manière la plus efficace possible.

Shift Right pour une défense immédiate

La protection en production permet de stopper l’hémorragie sur-le-champ et de protéger ainsi les données et les systèmes le temps que les équipes déterminent la vulnérabilité en cause. Cette mesure assure une défense immédiate de tous vos workloads, ce qui diminue drastiquement les risques de sécurité sans nécessiter la moindre modification du code.

En outre, l’analyse comportementale en production continue d’offrir la plus forte valeur en termes de rapidité de détection et de réponse aux attaques. Cette approche donne aux entreprises un éclairage sur le fonctionnement « normal » de leur environnement, de façon qu’elles puissent déceler plus facilement les anomalies dès leur apparition.

Les observations en production complètent également l’approche Shift Left en mettant au jour des vulnérabilités qui peuvent être corrigées en développement. Le partage de ces enseignements permet aux développeurs d’en tenir compte au cours des futurs cycles.

Vulnérabilité contre les attaques ciblant la logique métier

Dans le cas des API, les entreprises sont également sous la menace des attaques ciblant la logique métier, contre lesquelles l’approche Shift Left ne peut rien.

Les API ne sont pas simplement constituées de code qu’il suffit de vérifier pour déceler des failles au cours des phases de développement et de test. Elles permettent d’instancier la logique métier sous forme de code. Or, cette dernière ne peut pas être mise à l’essai au moyen d’une analyse de code statique. C’est pourquoi les outils destinés à tester la sécurité en préproduction n’offrent aucune protection contre les attaques ciblant la logique métiers des API. En l’absence d’analyse de la logique métier, les entreprises sont exposées à d’importants risques d’exploitation abusive des API : credential stuffing, piratage de compte, scraping, etc.

Pour déceler les failles de logique métier dans les API, vous devez observer les API en action et donc disposer de fonctionnalités de sécurité externes. Si les entreprises peuvent (et devraient) utiliser des outils de test de sécurité pour vérifier certains éléments de leur implémentation, comme les erreurs de configuration ou les vulnérabilités bien connues des API, elles doivent également comprendre leurs limites en ce qui concerne les attaques ciblant la logique métier.

Les tests en préproduction n’auraient jamais décelé la faille Log4j (Log4Shell), une vulnérabilité figurant potentiellement parmi les plus dangereuses et les plus répandues jamais mises au jour. Si l’on se penche sur le top 10 des menaces liées aux API établi par le projet OWASP, les six premières de la liste (classées par ordre de fréquence) découlent toutes de lacunes de la logique métier, contre lesquelles l’approche Shift Left n’est d’aucune utilité.

L’approche Shift Left est source de valeur, mais ne permet pas de satisfaire toutes les exigences de sécurité

L’approche Shift Left n’offre pas la vision d’ensemble nécessaire pour sécuriser une infrastructure, mais fournit plutôt une petite pièce du puzzle permettant de renforcer la sécurité des applications modernes. En effet, il s’avère tout simplement impossible pour vous de tester chaque élément en amont du déploiement.

Les outils de test ne sont pas conçus pour déceler toutes les utilisations abusives, et vous ne pouvez pas tout sécuriser dans le code. Les entreprises ont besoin d’une protection en cours d’exécution pour compenser les manquements en phase de développement, détecter les lacunes de sécurité inhérentes aux changements de code hors processus de programmation standard et mettre au jour les vulnérabilités inexploitables en préproduction.

Par conséquent, il apparaît justifié et important d’apprendre aux développeurs à mieux sécuriser le code et d’insister sur les mesures responsables de décalage à gauche. L’approche Shift Left est source d’une incroyable valeur pour les entreprises, car elle les aide à réfléchir stratégiquement au renforcement pérenne de leur position sur les questions de sécurité. Cependant, les entreprises ne peuvent pas se contenter de regarder vers l’avenir : elles doivent aussi veiller à protéger en priorité, dès maintenant, les actifs opérationnels dans leur environnement.