Patchs de vulnérabilités : le Cesin et le Cigref sont-ils bien raisonnables ?

Le Club des experts de la sécurité informatique et du numérique (Cesin) vient de publier une liste de 10 propositions à l’occasion de la campagne des élections présidentielles de 2022. Dans la pratique, celles-ci relèvent plus des doléances que des propositions exploitables, mais c’est plus nuancé pour celle touchant à la question des vulnérabilités. Là, le Cesin semble faire directement écho au Cigref.

Dès l’automne dernier, ce dernier demandait, entouré des associations Beltug, CIO Platform Netherlands et Voice, que « les produits et services numériques – notamment les logiciels – qui entrent sur le marché européen soient manifestement sûrs et répondent à des normes de sécurité numérique ». Ces associations estimaient ainsi que « l’industrie des produits et services numérique doit être soumise à de telles normes, afin que la responsabilité ne repose pas exclusivement sur l’utilisateur professionnel et puisse être partagée avec le fournisseur en cas de défaut de conception et de maintien en condition de sécurité ».

Selon elles, « l’effort de patching, c’est-à-dire la vérification et le déploiement sur tout le parc informatique des correctifs de sécurité de Microsoft, représente une mobilisation croissante de ressources chez les clients de l’éditeur pour pallier les défauts de qualité et de sécurité de ses produits et services ». Le Cesin va simplement plus loin, en ne limitant pas son propos au seul géant de Redmond.

Le fait est que les vulnérabilités sont découvertes en grand nombre chaque année, depuis plusieurs années. Les correctifs associés ne manquent pas. Et l’on peut déplorer que certains d’entre eux, dont un, récent, pour Windows Server, présentent un niveau de qualité insuffisant, alimentant par là même la frilosité de certaines organisations, au risque de pénaliser leur posture de sécurité. Mais de tels cas restent marginaux.

En outre, parmi les correctifs concernant les vulnérabilités les plus critiques largement exploitées par les cyberdélinquants, beaucoup touchent des systèmes embarqués. Et déployer un correctif pour une appliance Citrix, Fortinet, Palo Alto Networks ou Pulse Secure n’a pas grand-chose à voir avec le travail nécessaire pour un autre, touchant un contrôleur de domaine ou un ERP marqué par la complexité liée à des développements à façon.

Reste que ces atermoiements ont de quoi surprendre, en particulier du Cesin, un club d’experts de la sécurité informatique : la gestion des vulnérabilités et des correctifs est au cœur de leur métier. Que le Cigref monte au créneau est peut-être plus compréhensible. Toutefois, la démarche interroge : des organisations de la taille de ses membres ne disposent-elles pas des outils nécessaires à l’industrialisation de la gestion des correctifs ? À moins que les commerciaux de Tenable, Rapid7, Patrowl, Qualys ou encore Onyphe n’aient pas correctement fait leur travail. Car il y a clairement là de quoi identifier les systèmes affectés et hiérarchiser le travail de déploiement en fonction de la menace réelle. Sans compter avec les alertes régulières du CERT-FR.

Qui plus est, des organisations telles que le Cesin et le Cigref ne sont-elles pas en capacité de mettre en place une sorte de laboratoire commun pour qualifier les correctifs dans un contexte donné et fournir des recommandations de déploiement à leurs adhérents ?

Quoi qu’il en soit, le Cigref demandait à l’automne dernier à Microsoft « de prendre ses responsabilités, en termes de garantie constructeur, et de participer aux surcoûts engendrés par sa politique de correctifs de sécurité ». Une façon de dire à l’éditeur que les coûts qu’il supporte déjà pour le développement de ses produits, puis celui de correctifs, lorsque lui sont signalées des vulnérabilités, ne constituent pas un investissement suffisant de sa part. Et qu’à travers cela, il ne prendrait donc pas déjà ses responsabilités.

Cette position peut apparaître d’autant plus paradoxale que le Cigref demande en parallèle à l’éditeur « de garantir à ses clients le maintien des services de support et des correctifs de sécurité sur ses logiciels sans limitation de durée, et ce, en contrepartie d’un effort financier raisonnable pour le client ». 

Et de rappeler à l’automne dernier que « cette demande était déjà formulée par le Cigref et ses associations sœurs belge et néerlandaise dans leur communiqué de presse d’avril 2020 ». À se demander si ce n’était pas un poisson.

Mais développer du logiciel intrinsèquement sûr relève-t-il de l’utopie ? À une certaine échelle, à un certain niveau de complexité, ça semble effectivement être le cas. Le monde du logiciel embarqué dans l’aviation est par exemple soumis à des standards rigoureux. Mais ceux-ci n’empêchent pas la présence de vulnérabilités. Et les cycles de vie ne sont pas véritablement comparables à ceux de l’IT, tout comme l’exposition des systèmes affectés à des menaces effectives.

« La sécurité est testable jusqu’à un certain point. Lorsque l’on teste, on suppose toujours quelque chose. Et sur l’attaquant, on ne peut rien supposer ».

Le test logiciel n’est pas exempt de défaut. Comme le relevait Gérard Berry, professeur au Collège de France, à l’occasion de l’édition 2015 du Forum International de la Cybersécurité, « la sécurité est testable jusqu’à un certain point. Lorsque l’on teste, on suppose toujours quelque chose. Et sur l’attaquant, on ne peut rien supposer ».

La promesse des méthodes formelles ? Elles n’ont rien de magique : elles permettent surtout de « donner des garanties mathématiques quant à l’absence de certains défauts » en prouvant la conformité d’une implémentation vis-à-vis d’une spécification.

Au final, tant le Cigref que maintenant le Cesin semblent vouloir au moins en partie ignorer, voire refuser, que la sécurité d’un système est un processus dynamique, impliquant inexorablement le développement et le déploiement de mises à jour. Cela peut être désagréable, mais cela semble bel et bien inévitable.

Le Français ProvenRun semble l’avoir d’ailleurs bien admis : il propose, avec ProvenFOTA, une « application logicielle sécurisée » destinée aux systèmes embarqués pour assurer que « le firmware de l’appareil reste authentique » et qu’il n’est pas possible de revenir à une version antérieure. Autrement dit : il s’agit de sécuriser… le déploiement de mises à jour.

Mais peut-être verra-t-on, un jour, une class action contre Apple, Google ou Samsung demandant dédommagement pour les périodes d’indisponibilité régulières des terminaux lors de leurs inévitables mises à jour. À moins que des consommateurs ne s’en prennent plutôt à des constructeurs automobiles.