Le 13 avril dernier, l'Agence de cybersécurité et de sécurité des infrastructures (Cisa), le FBI et la NSA, en collaboration avec les autorités de cybersécurité de plusieurs pays occidentaux, ont publié un document appelant les entreprises technologiques à adopter la security by design, ou « sécurité dès la conception », pour leurs produits.
« Historiquement, les fabricants de technologies sont partis du principe que les vulnérabilités devaient être résolues après que les clients ont acheté leurs produits, requérant ainsi d'eux qu'ils réalisent ces opérations à leur charge », développe le document. Pour atteindre un haut standard de sécurité logicielle, les agences « encouragent les fabricants à faire de la sécurité une priorité, devant les caractéristiques du produit et la mise sur le marché. »
Qu'est-ce que la sécurité dès la conception ? Quels bénéfices apporte-t-elle et comment les entreprises technologiques peuvent-elles la mettre en pratique ? Eléments de réponse avec Stephen de Vries, PDG et cofondateur d'IriusRisk, entreprise spécialisée dans cette approche.
LA TRIBUNE - IriusRisk affirme identifier les failles de sécurité dans l'architecture logicielle dès la phase de conception, et ainsi les résoudre avant même que le code ne soit écrit. En quoi cette approche est-elle plus intéressante que celle consistant à tester et corriger le code de manière itérative ?
STEPHEN DE VRIES - Cette approche suit une logique actuellement à l'œuvre dans le monde de la cybersécurité, et plus généralement dans celui du développement de logiciel : celui du décalage à gauche. Autrement dit, le fait d'accomplir la plus grosse partie du travail dès le début du processus de développement, car plus vous vous y prenez tard, plus il devient compliqué de changer quelque chose.
Il s'agit, en somme, de se rapprocher du processus de construction d'un objet physique : on conçoit un plan, on s'assure qu'il fonctionne bien et qu'il est conforme à ce que l'on désire, puis on construit et on vérifie à la fin qu'on a bien fait ce qui était prévu au départ. Dans la sécurité du logiciel, on fait traditionnellement peu de planification et l'on se repose principalement sur une batterie de tests pour s'assurer qu'on est capable de résister aux cyberattaques. Pour ce faire, la plupart des entreprises recourent à une société tierce pour effectuer les tests en fonction des meilleures pratiques du secteur.
Quel est le défaut de cette approche ?
Tout l'enjeu consiste à savoir quoi tester. Or, nous l'avons dit, ces tests sont, en général, réalisés par une entreprise tierce, qui mobilise ses experts dans cette optique. Ceux-ci disposent d'une solide connaissance en matière de cybersécurité, mais ils n'ont pas l'expérience métier dont bénéficie la société cliente. S'ils savent donc très bien se mettre dans la peau des hackers et simuler les grands types d'attaques qu'ils seraient susceptibles de lancer contre le logiciel, il leur manque certaines clés. Par exemple, si vous concevez une application de paiement et souhaitez que chaque transaction soit vérifiée et validée, il s'agit d'une fonctionnalité unique à votre application, et les testeurs ne sauront pas forcément qu'ils doivent vérifier qu'elle fonctionne bien et ne présente aucune vulnérabilité.
De même, lorsqu'un architecte logiciel décide de concevoir son application, certains impératifs en matière de cybersécurité peuvent lui échapper. Il se peut, par exemple, que lorsqu'on choisit de stocker ses données sur AWS, il faille recourir à telle application pour permettre aux flux de données de se mouvoir en toute sécurité. S'il l'ignore et ne le fait pas dès le départ, il aura une mauvaise surprise à la fin, et cela lui demandera beaucoup plus de travail pour corriger son erreur. C'est la raison pour laquelle le décalage à gauche est intéressant. Le monde du logiciel a tendance à bouger très vite et à rectifier le tir en cours de route. C'est une approche qui a ses avantages, mais elle rencontre aujourd'hui ses limites en matière de cybersécurité.
Quelles transformations sur le marché du logiciel ont rendu la sécurité dès la conception nécessaire, selon vous ?
Lorsque j'ai commencé à travailler dans la cybersécurité, au début des années 2000, les applications étaient beaucoup moins complexes qu'aujourd'hui. On comptait peu d'architectures logicielles et de librairies, et le nombre de failles sécuritaires que l'on pouvait laisser par inadvertance dans une application n'était donc pas énorme. Dans ce contexte, le fait de se reposer uniquement sur des tests en cours de route avait du sens. Réaliser quelques tests standards était tout simplement l'approche la plus efficace et économe de s'assurer qu'une application était sécurisée. C'est la raison pour laquelle elle s'est imposée.
Depuis, l'univers du logiciel s'est considérablement complexifié. Aucune application n'est plus liée à une seule base de données : on stocke des données partout, dans des zones qui ont des régulations différentes en place, on a un large choix de librairies et d'architectures à sa disposition, toute une armée de microservices qui viennent interagir avec les applications. En un mot, le niveau de complexité est bien supérieur.
Dans un tel contexte, le nombre de tests nécessaires pour s'assurer qu'une application est sécurisée est virtuellement infini. Par conséquent, effectuer des tests de sécurité ne suffit plus. Malgré ce changement, la mentalité selon laquelle le logiciel, étant immatériel, est toujours facile à modifier et à corriger, est encore très présente. Mais avec la complexité croissante des architectures, c'est de moins en moins vrai.
L'évolution des régulations en matière de cybersécurité doit-elle refléter ce changement ? Les gouvernements sont-ils bien informés à ce sujet ?
Les autorités américaines en ont bien conscience : tout logiciel utilisé par le gouvernement fédéral doit désormais se plier au Secure Software Development Framework (SSDF), un ensemble de règles qui incluent le principe de la sécurité dès la conception.
La Food and Drug Administration (FDA) insiste également sur ce principe. Pour obtenir l'homologation d'un appareil médical, il est désormais nécessaire d'expliquer comment les menaces potentielles ont été modélisées dès la phase de conception et quels choix ont été faits en matière de cybersécurité.
Le Cyber Resiliency Act européen reste malheureusement pour l'heure assez flou sur la question. Il requiert des mesures « adéquates » de la part des fabricants pour protéger leurs logiciels, sans vraiment s'attarder sur ce que signifie « adéquates », ce qui laisse le fournisseur en décider par lui-même. Ce n'est naturellement pas idéal.
Sujets les + commentés