Oscar Prado, Romande Energie: «Nous avons une plateforme qui génère les données SBOM»

Résumez-nous l’approche et les pratiques de ­Romande Energie en matière de sécurité des applications?

La sécurité de nos applications est cruciale: nous ne pouvons pas prendre le risque d’une intrusion dans nos systèmes, potentiellement suivie de mouvements latéraux qui pourraient, dans le pire des cas, mener à un blackout. Pour prévenir ce risque, nous avons mis en place un processus de due diligence axé sur la cybersécurité et la protection des données pour toutes les applications ou plateformes que nous déployons, et ce, sans exception. La vérification porte sur la dimension organisationnelle – nous évaluons la posture de cybersécurité des fournisseurs – de même que sur la solution elle-même. Nous nous renseignons sur tous les aspects liés à la protection des données, y compris techniques, notamment concernant les mesures de sécurisation des données au repos et en transit. Nous réalisons aussi un audit de sécurité indépendant avant l’intégration de chaque solution, puis régulièrement à un rythme annuel. Cette approche porte ses fruits. Récemment, nous souhaitions collaborer avec un fournisseur mais nous avons finalement renoncé car la due diligence n’a pas convaincu. Nous avons bien fait car quelques mois plus tard, le fournisseur a vu ses logiciels compromis.

Que faites-vous contre les potentielles vulnérabilités des multiples éléments disparates qui composent la supply chain logicielle, notamment les composants open source? 

Nous avons une approche dite shift-left qui consiste à intégrer la sécurité dès la première phase de développement des applications, puis au fur et à mesure. Cette approche DevSecOps amène les équipes de développement et celles chargées de la sécurité à collaborer dès le début d’un projet. Nous disposons par ailleurs d’une plateforme extrêmement précieuse qui génère les données SBOM, les software bill of materials. Cette solution nous donne un paysage applicatif complet, incluant toutes les dépendances, qui sont repérées automatiquement. Lors de la découverte de la faille dans Log4j, nous avons ainsi été capables d’identifier très rapidement dans quelles applications cette bibliothèque était utilisée, alors même que nous avons un écosystème des plus complexes. Nous sommes aussi en train de déployer une nouvelle solution qui va permettre de faire ce qu’on appelle du patching chirurgical. A cela s’ajoute une plateforme capable d’analyser en temps réel les vulnérabilités applicatives de l’ensemble de nos systèmes, de même que des tests mensuels de sécurité dynamique des applications.

Pouvez-vous en dire davantage au sujet des tests d’applications?

Nous prévoyons de généraliser le test des applications en procédant à une analyse du code statique en mode boîte blanche, sans l’exécuter, en complément des analyses dynamiques. En cas de faille détectée, notre plateforme va générer un feedback et permettre au développeur concerné d’améliorer sa pratique. Je peux également mentionner notre outil SCA, qui sert à automatiser le processus d’inspection des gestionnaires de packages des fichiers et du code source. Un autre aspect important réside dans l’analyse des images de containers et des fonctionnalités serverless. Les différentes découvertes résultant de ces processus sont ensuite intégrées aux nomenclatures SBOM.

Etes-vous également utilisateur de SBOMs mis au point directement par les fournisseurs?

Certains fournisseurs sont très matures à ce niveau, tandis que d’autres ne sont pas forcément capables de renseigner sur les différentes dépendances applicatives de leurs solutions. C’est typiquement quelque chose que nous vérifions lors de la procédure de due diligence. Ceci dit, dans le cas où ces nomenclatures ne seraient pas déjà produites, il est parfois envisageable de collaborer avec le fournisseur pour en créer, dans une optique gagnant-gagnant.