Lorsque l’on est un développeur soucieux de la sécurité, contribuer à un projet de développement d’un système hérité est un véritable casse-tête. Cela revient à démarrer les travaux d’une vieille maison en ruine qui repose sur des fondations fissurées. Par où commencer quand les problèmes rencontrés sont aussi variés que critiques ?

Une application d’un système hérité peut voir sa sécurité menacé par des dépendances non maintenues avec d’anciennes versions de bibliothèques logicielles, une mauvaise configuration, ou même utiliser des protocoles non sécurisés et des composants open source présentant des vulnérabilités connues, comme la vulnérabilité récemment découverte CVE-2021-44228 (log4j).

Si l’on poursuit l’analogie de la maison, on peut comparer les dépendances non maintenues à un toit endommagé. Si on ne s’en occupe pas tout de suite, le problème va s’empirer jusqu’à devenir critique. L’utilisation de protocoles non sécurisés s’apparente à une serrure de porte cassée et représente donc une aubaine pour les intrus. Les fondations fissurées font quant à elles penser aux bibliothèques open source vulnérables. Un désastre peut survenir à tout moment, un acteur malveillant s’attaquant à une application aura les mêmes effets qu’une tempête faisant écrouler une maison. Hiérarchiser les problèmes de sécurité semble ainsi compliqué, voire impossible, et il peut être tentant pour les développeurs de faire le choix de tout détruire pour reprendre à zéro.

Mesurez l’impact et les efforts à fournir

L’adoption d’un système simple pour hiérarchiser les actions à entreprendre est une première étape. En évaluant les bénéfices que peut avoir une correction en fonction de la gravité de la vulnérabilité, il sera ainsi possible de prioriser celles qui sont critiques et celles relevant seulement d’une bonne hygiène cyber.

Après avoir hiérarchisé les problèmes de sécurité, il faut maintenant s’atteler à évaluer les efforts qu’ils vont demander pour être résolus. Par exemple, le remplacement d’une grande partie de la fonctionnalité vulnérable sera beaucoup plus contraignant que le remplacement d’une dépendance par une autre version mise à jour.

Après avoir mis en place ce processus d’évaluation, la liste de tâches se retrouve divisée en quatres grandes catégories :

  • Les tâches avec un impact important mais qui ne nécessitent pas beaucoup d’efforts de correction doivent être traitées en priorité car elles feront rapidement une grande différence au niveau de la sécurité de l’application.
  • Les tâches avec un impact conséquent et qui sont compliquées à traiter sont celles dont il faut s’occuper dans un second temps après les plus faciles à corriger
  • Les tâches ayant un faible impact et facilement traitable doivent figurer en arrière-plan, il faut s’en occuper ponctuellement entre deux tâches plus importantes.
  • Les tâches complexes sans grandes conséquences sont à placer en bas de la liste. Il est intéressant de prendre du recul sur ce type de tâches afin de définir la meilleure approche pour agir le plus efficacement possible.

N’oubliez pas l’exploitabilité

L’évaluation de l’effort et de l’impact peut aider à trier efficacement la liste de corrections à faire. Cependant, cette stratégie ne fonctionne pas pour les listes très longues ou lors d’une première mise en conformité de la sécurité d’une application. Il faut alors inclure une troisième dimension qui peut être l’exploitabilité.

Une application est susceptible de présenter des vulnérabilités exceptionnelles telles que des problèmes de longue date qui impliquent quasiment tous les systèmes d’exploitation et langages de programmation ou des cas limites liés à de nombreuses bibliothèques open source courantes. Néanmoins, si toutes les conditions nécessaires à l’exploitation des vulnérabilités ne sont pas réunies, elles sont moins urgentes à traiter. C’est notamment le cas pour les vulnérabilités qui ne sont pas visibles par les cyber attaquants et les commandes présentant une vulnérabilité qui n’est liée à aucun projet. À noter que, tôt ou tard, toutes les vulnérabilités devront être corrigées car le contexte peut évoluer et exposer une vulnérabilité qui n’était jusqu’à présent pas exploitable.

Ajouter une troisième dimension permet de trier et prioriser les vulnérabilités afin de les traiter efficacement, quel que soit le degré d’avancement du projet. Pour cela vous aurez besoin d’outils, surtout lorsque la liste des corrections est longue. C’est à ce moment que l’automatisation s’avère particulièrement importante pour aider les entreprises à lutter contre les cybermenaces. Trier et prioriser les corrections et changements nécessaires est indispensable pour améliorer la sécurité d’une application. Appliquer des méthodes et des solutions au service des développeurs permet d’accélérer ses étapes nécessaires à la garantie de la sécurité continue des applications.