Quand l'information est-elle "trop d'information" ?

Joao Correia

14 avril 2023 - Évangéliste technique

Vous avez certainement remarqué la tendance - elle est difficile à manquer si vous avez été attentif. Les listes de modifications sont de plus en plus clairsemées, surtout depuis un an environ. Parfois, un simple "bogues corrigés" ou "améliorations des performances" est tout ce qui est offert pour décrire ce qui a été fait exactement entre les versions. Il existe des raisons assez convaincantes pour ce changement, ainsi que plusieurs contre-arguments tout aussi intéressants.

L'époque où il y avait plus de paragraphes de texte décrivant un changement de code que de lignes de code pour ce changement est révolue. Les changelogs étaient des morceaux de texte passionnants, rédigés avec une calligraphie capable de faire réfléchir certains auteurs littéraires sur leur choix de carrière. C'était le bon temps.

Mais cette époque est désormais révolue. Prenez n'importe quelle liste de modifications des mises à jour de Windows, et vous devrez creuser profondément pour voir ce qui n'allait pas exactement et qui nécessitait une correction, et ce qui a été fait pour résoudre le problème. L'entrée en vigueur de cette politique il y a quelques années a suscité une levée de boucliers (très bruyante), mais Microsoft n'a pas cédé et cette politique est toujours en vigueur aujourd'hui, qu'il s'agisse de produits grand public ou de produits professionnels.

On pourrait penser que Microsoft est simplement Microsoft et qu'il s'agit là d'une pratique courante de la part des "grandes entreprises". Mais si l'on regarde de l'autre côté de l'allée, disons le noyau Linux, on constate que la même chose se produit. Bien sûr, vous pouvez suivre toutes les discussions, les commentaires et les fils de discussion sur de nombreux forums concernant les bogues, les vulnérabilités et les nouvelles fonctionnalités du noyau, mais lorsque vous examinez le journal des modifications lui-même, vous avez du mal à identifier les correctifs de sécurité spécifiques apportés à une version donnée.

La sécurité par l'obscurité a tendance à ne pas durer très longtemps, mais c'est une ligne fine que les développeurs sont en train de tracer ici.

Les problèmes de sécurité

Les partisans de la réduction de la quantité d'informations dans les changelogs affirment souvent qu'ils sont (sans ordre particulier) :

Réduire les informations dont disposent les acteurs malveillants pour identifier de nouvelles vulnérabilités présentes dans des versions plus anciennes, déjà déployées (et donc vulnérables) ;
Donner un peu de temps aux "bons" pour corriger leurs systèmes avant que les pirates ne commencent à essayer de les pénétrer, car le délai entre la divulgation d'une vulnérabilité et l'apparition d'exploits "dans la nature" est de plus en plus court, de l'ordre de quelques minutes seulement ;
En affirmant que les utilisateurs n'ont pas besoin de connaître tous les petits détails puisqu'ils sont censés prendre la dernière version dès que possible ; c'est le principe de base de la cybersécurité que de toujours appliquer les correctifs.

Cependant, il existe des arguments tout aussi convaincants de l'autre côté :

Les mauvais acteurs disposent des ressources, du savoir-faire et de la motivation nécessaires pour comparer les différences de code réelles entre les versions et n'ont pas vraiment besoin des listes de modifications. Cette situation est encore aggravée par le fait que les robots d'intelligence artificielle peuvent désormais fournir une assistance dans cette tâche, ce qui banalise le niveau de connaissance requis.
En cachant ces détails, il est plus difficile, voire impossible, d'établir un ordre de priorité pour les correctifs à apporter, car il n'existe pas de mesure de risque comparable à évaluer.
Prendre la dernière version à chaque fois n'est pas toujours totalement sûr, car aucun correctif n'a jamais eu de conséquences inattendues, n'est-ce pas ?

Les discussions à ce sujet peuvent très vite s'envenimer et il est facile de passer à côté de l'essentiel et de sombrer dans des arguments du type "je sais mieux que quiconque" qui sont en fin de compte improductifs. Cependant, ces débats mettent effectivement en lumière un problème qui a des effets tangibles sur la sécurité. Il est indéniablement vrai que vous devez toujours veiller à ce que vos systèmes utilisent la version la plus récente de tous les logiciels qui s'y trouvent. Mais des événements courants tels que la perte de support matériel ou des changements dans le champ d'application, les exigences ou la disponibilité peuvent rendre cette tâche impossible. Dans ce cas, le manque d'informations est plus un obstacle qu'une aide, car vous n'avez aucun moyen d'identifier une nouvelle vulnérabilité à laquelle vous êtes désormais exposé - jusqu'à ce que quelque chose de grave se produise.

Le fait de ne pas identifier explicitement les problèmes de sécurité en tant que tels signifie également que vous ne demanderez pas (ou ne retarderez pas la demande) d'un CVE pour le problème. Dans un domaine comme la cybersécurité, qui se concentre presque exclusivement sur le suivi, la gestion, l'analyse et la correction des CVE, le fait d'avoir des problèmes de sécurité qui échappent à tous les outils et à la surveillance est, pour le moins, discutable.

Où nous allons

Il se peut qu'à un moment donné, les changelogs n'aient plus aucune valeur.

Sur les builds de Windows Server Insider, il n'y en a même pas - et l'ironie de la chose, c'est que vous exécutez une version bêta en effectuant des tests gratuitement et que vous n'avez aucun moyen de savoir ce que vous êtes censé tester. Cette situation pourrait devenir la norme plutôt que l'exception. Les versions grand public des systèmes d'exploitation ne permettent plus d'accéder facilement à la description des correctifs, qui ne contient plus qu'une mention générique "bugs corrigés". Il faut creuser plus profondément pour trouver plus de détails, et même cela devient progressivement accessible à un public plus restreint.

Encore une fois, il est important de souligner que cette approche n'est pas liée uniquement aux logiciels à code source fermé. Le monde du logiciel libre adopte également cette approche. En fait, cela crée une situation particulière pour les projets à code source ouvert. D'une part, le code source est librement accessible, les rapports de bogues sont disponibles et les développeurs sont incités à corriger les bogues et à ajouter des fonctionnalités. Mais d'un autre côté, vous cachez délibérément des informations qui pourraient aider à accomplir ces tâches. Il y a là quelque chose qui ne colle pas.

Il existe une très longue liste d'arguments autour de ce débat que vous pouvez trouver dans ce filoù certains leaders du Kernel discutent des mérites de l'approche qu'ils ont choisie pour cette question - ainsi que des nombreuses critiques qui l'accompagnent.

L'impact de l'IA

L'IA évolue rapidement et il est difficile de se tenir au courant de toutes les nouvelles fonctionnalités. Mais l'une des caractéristiques bien établies des robots d'IA actuels est leur capacité à vous aider à comprendre et à trouver des problèmes dans le code. Il est facile de coller un bloc de code avant et après dans l'interface de discussion d'un robot d'IA et de lui demander de "trouver les bogues qui ont été résolus avec ces changements de code" et "comment ces bogues pourraient être exploités".

Les logiciels à code source ouvert ressentiront cet impact beaucoup plus rapidement que les logiciels à code source fermé, car l'accessibilité jouera en leur défaveur à cet égard. La vérification des différences entre les différentes versions d'un logiciel afin d'identifier les failles de sécurité était déjà une activité à laquelle s'adonnaient les acteurs de la menace, et la barre a maintenant été considérablement abaissée. Mais il ne suffit pas que les bons éléments aient la disponibilité et les ressources nécessaires pour le faire eux-mêmes - ils ont d'autres préoccupations que de se concentrer uniquement sur la recherche et l'exploitation des bogues.

L'"obscurité" dans la "sécurité par l'obscurité" est sur le point d'être bien éclairée.

Les balles magiques ou leur absence

Il n'y a pas de solution miracle à ce problème. Jusqu'à présent, il s'est avéré insoluble et, incroyablement, chacun est convaincu que sa propre approche est la meilleure, ce qui explique pourquoi il procède de cette manière. Cela peut être aussi extrême que d'avoir trois applications logicielles différentes sur un système, toutes avec des approches différentes - le système d'exploitation, le serveur web et la base de données. En fin de compte, quelqu'un paie le prix de cette approche disparate du partage (ou de la dissimulation) de l'information, et cela constitue un obstacle supplémentaire que les professionnels de l'informatique doivent surmonter pour faire efficacement leur travail.

En fin de compte, le débat autour des changelogs et de la quantité d'informations qui y sont partagées est complexe et présente de multiples facettes. Alors que la technologie et l'IA continuent d'évoluer, l'industrie devra peut-être réévaluer son approche de la sécurité et du partage d'informations afin de trouver un équilibre entre transparence et protection.