19
Premières notions de sécurité
Chapitre 1
finition des failles de sécurité découvertes et donc virtuellement corrigées, alors
que l’absence d’avis relatifs à tel système commercial pouvait simplement signifier
que l’on passait sous silence ses défauts de sécurité en profitant de son opacité. Or
l’expérience montre que tout dispositif de sécurité a des failles ; les attaquants ne
perdent pas leur temps à faire de la recherche fondamentale sur la factorisation des
grands nombres entiers, ils essaient de repérer les failles d’implémentation et ils les
exploitent. Face à ce risque, la meilleure protection est une capacité de riposte rapide, qui consiste le plus souvent à commencer par désactiver le composant pris en
défaut en attendant la correction. La communauté du logiciel libre excelle dans cet
exercice, mais avec les logiciels commerciaux les utilisateurs n’ont souvent aucun
moyen d’agir : ils ne peuvent qu’attendre le bon vouloir de leur fournisseur. Dans
ce contexte, la publication d’avis des CERT relatifs à des logiciels commerciaux
est très bénéfique parce qu’elle incite les fournisseurs à corriger plus rapidement
un défaut dont la notoriété risque de nuire à leur réputation. Mais certains fournisseurs cherchent à obtenir le silence des CERT en arguant du fait que leurs avis
risquent de donner aux pirates des indications précieuses... ce qui est fallacieux car
les sites Web des pirates sont de toute façon très bien informés et mis à jour, eux,
selon les principes du logiciel libre, ce qui indique bien où est l’efficacité maximale. L’expérience tend à prouver qu’une faille de sécurité est d’autant plus vite
comblée qu’elle est publiée tôt et largement. L’accès au code source du logiciel en
défaut constitue bien sûr un atout.
La réponse à la question posée par le titre de cette section est donc : oui, il faut
publier les failles de sécurité, mais de façon organisée et responsable, c’est-à-dire de
façon certifiée, sur le site d’un organisme accrédité, typiquement un CERT, et
après avoir prévenu l’auteur ou l’éditeur du logiciel en défaut et lui avoir laissé un
délai raisonnable pour au moins trouver un palliatif d’urgence. Il faut savoir qu’il
existe aujourd’hui un marché de la faille, qui parfois n’est pas loin de s’apparenter
à du chantage.
Premières notions de sécurité
Chapitre 1
finition des failles de sécurité découvertes et donc virtuellement corrigées, alors
que l’absence d’avis relatifs à tel système commercial pouvait simplement signifier
que l’on passait sous silence ses défauts de sécurité en profitant de son opacité. Or
l’expérience montre que tout dispositif de sécurité a des failles ; les attaquants ne
perdent pas leur temps à faire de la recherche fondamentale sur la factorisation des
grands nombres entiers, ils essaient de repérer les failles d’implémentation et ils les
exploitent. Face à ce risque, la meilleure protection est une capacité de riposte rapide, qui consiste le plus souvent à commencer par désactiver le composant pris en
défaut en attendant la correction. La communauté du logiciel libre excelle dans cet
exercice, mais avec les logiciels commerciaux les utilisateurs n’ont souvent aucun
moyen d’agir : ils ne peuvent qu’attendre le bon vouloir de leur fournisseur. Dans
ce contexte, la publication d’avis des CERT relatifs à des logiciels commerciaux
est très bénéfique parce qu’elle incite les fournisseurs à corriger plus rapidement
un défaut dont la notoriété risque de nuire à leur réputation. Mais certains fournisseurs cherchent à obtenir le silence des CERT en arguant du fait que leurs avis
risquent de donner aux pirates des indications précieuses... ce qui est fallacieux car
les sites Web des pirates sont de toute façon très bien informés et mis à jour, eux,
selon les principes du logiciel libre, ce qui indique bien où est l’efficacité maximale. L’expérience tend à prouver qu’une faille de sécurité est d’autant plus vite
comblée qu’elle est publiée tôt et largement. L’accès au code source du logiciel en
défaut constitue bien sûr un atout.
La réponse à la question posée par le titre de cette section est donc : oui, il faut
publier les failles de sécurité, mais de façon organisée et responsable, c’est-à-dire de
façon certifiée, sur le site d’un organisme accrédité, typiquement un CERT, et
après avoir prévenu l’auteur ou l’éditeur du logiciel en défaut et lui avoir laissé un
délai raisonnable pour au moins trouver un palliatif d’urgence. Il faut savoir qu’il
existe aujourd’hui un marché de la faille, qui parfois n’est pas loin de s’apparenter
à du chantage.