La mise en place du CRA va imposer aux éditeurs et aux industriels une gestion très rigoureuse des vulnérabilités et surtout de la nomenclature de leurs solutions. De quoi imposer une approche outillée et structurée.
Pour les grands éditeurs de logiciels et quelques gros industriels, le concept de Secure by Design s’est imposé il y a plusieurs années, et gérer les vulnérabilités et la publication des correctifs de sécurité sont aujourd’hui des processus bien industrialisés. Mais c’est loin d’être le cas des petits éditeurs et des industriels.
Un SBOM à jour : la base de l’approche
Le Cyber Resilience Act (CRA) va pousser de nombreuses entreprises à s’équiper en solutions plus pérennes que des feuilles Excel pour pouvoir prétendre garder le logo CE sur leurs produits. Car le CRA stipule clairement que l’éditeur doit établir une nomenclature logicielle (SBOM / Software Bill of Materials) dans un format lisible par les machines afin de couvrir, au minimum, les dépendances de premier niveau de son produit.
Un SBOM à jour va être indispensable pour identifier les vulnérabilités dans l’ensemble des composants, y compris Open Source, qui entrent dans la composition du logiciel, mais aussi de son infrastructure d’exécution, notamment l’OS mis en œuvre. La collecte des CVE et surtout le tri et la hiérarchisation des vulnérabilités va certainement pousser des éditeurs vers la mise en place de solutions plus industrielles qu’un suivi manuel.
Les 8 exigences du CRA vont pousser en ce sens, mais le respect du texte incite à structurer les processus pour éviter toute sanction en cas d’incident. Mejdi Arfaoui, spécialiste Cyber & GRC chez Alten explique : « en termes d’outillage, il existe actuellement énormément d’outils de GRC, dont plusieurs sont capables de supporter une grande partie des exigences du CRA. Ces plateformes permettent de saisir l’ensemble des informations et des évidences et d’effectuer le suivi des incidents dans le temps ».
Le consultant souligne le risque de cette approche, car le danger est que les informations saisies ne soient pas correctes. L’entreprise peut alors présenter un rapport qui indique qu’elle est conforme aux exigences du texte, mais dans les faits, il n’en est rien : « dans une telle situation, le risque est très élevé pour l’entreprise en cas d’incident. L’outil ne fait pas tout et il est nécessaire de se faire aider par des consultants ayant une grosse expérience dans la mise en conformité ».
De même, les recettes déjà déployées dans d’autres secteurs vont pouvoir s’appliquer. C’est notamment le cas entre DORA et du CRA.
Les 8 exigences du CRA sur la gestion des vulnérabilités :
Identifier les vulnérabilités et les composants contenus dans le produit,
Remédier sans délai aux vulnérabilités, notamment en fournissant des mises à jour de sécurité,
Appliquer des tests et des examens efficaces et réguliers de la sécurité du produit ;
Partager et divulguer publiquement des informations sur les vulnérabilités corrigées,
Mettre en place et appliquer une politique de divulgation coordonnée des vulnérabilités (CVD pour Coordinated Vulnerability Disclosure),
Prendre des mesures pour faciliter le partage d’informations sur les vulnérabilités,
Prévoir des mécanismes de distribution sécurisée des mises à jour,
Veiller à ce que les mises à jour de sécurité disponibles soient diffusées sans délai.
Pour se mettre en conformité, Haas Avocats propose un plan d'action en 90 jours qui commence par un audit, puis de la formation, un exercice de crise, et se termine par une certification. Les modèles juridiques sont validés pour toute l'Europe, une assistance est assurée en 24/24 avec un avocat d'astreinte, la responsabilité est partagée avec le DSI.
L’offre s’adresse notamment aux entreprises qui seront concernées par le CRA, mais qui n’ont pas nécessairement de RSSI ou de CISO pour se saisir du sujet. Baptisée protocole de notification 24/72, « ce protocole assure d'être rapide et précis à chaque moment, depuis l'alerte initiale à la réunion de crise avec le DSI et son RSSI, jusqu'à l'envoi de l'alerte à l'ENISA et la soumission du rapport final », résume Maître Gérard Haas, avocat associé fondateur de Haas Avocats.
« En cas de crise, il n’est plus temps d’improviser. L'efficacité dépend d'une préparation en amont. »
Maître Gérard HaasAvocat associé fondateur de Haas Avocats
Il est aussi possible de s’appuyer sur une solution de GRC (Gestion du Risque et de la Conformité) pour assurer la traçabilité des processus liés à la conformité. Romain Bogdanovic, fondateur du service Owlcub propose un outil GRC utilisable par des non-spécialistes. La solution intègre les référentiels les plus connus en France, comme l’ISO 27001, NIS 2 ainsi que le référentiel de sécurité du NIST : « en tant qu’éditeur, nous avons décidé d’implémenter le CRA pour l’appliquer à nous-même. L’objectif de l’outil n’est pas de donner une certification à la personne qui l’utilise, mais bien l’accompagner dans son pilotage de la sécurité ».
Le logiciel de GRC peut se connecter à un dépôt Git, par exemple, mais l’information relative au code ne suffit pas, puisque les risques couvrent toute l’infrastructure, OS et équipements compris : « à partir du moment où vous déclarez vos ressources dans l’outil, la solution va aller rechercher dans les bases de CVE d’accès public les failles connues en fonction des équipements, de la solution déployée et de sa version », détaille Romain Bogdanovic. Cette information permet de savoir quels sont les composants de la plate-forme à mettre à jour.
Mais ce n'est pas tout : « nous proposons aussi en add-on un SAST (outil d'analyse de code statique) qui va scanner le code et accompagner les développeurs dans, justement, sa montée en compétences vers le Security by design ». La solution est notamment mise en œuvre par les MSP et ESN qui assurent le suivi de la conformité pour leurs clients.
Pour approfondir sur Gestion des vulnérabilités et des correctifs (patchs)
