2007 : la sécurité éparpillée, façon puzzle
Alors que les vendeurs d'antivirus et proches cousins tente d'appâter le chaland à coup de statistiques catastrophistes -Bilan Sécu 2006 : on l'a échappé belle- et de prévisions apocalyptiques -Prospectives Sécu 2007 : on n'a pas fini d'en baver-, les spécialistes sécurité, bloguent moins sur les actes des pirates que sur les tentatives de détournement des éditeurs eux-mêmes. Par qui allons-nous être mangés ? Et surtout « combien tout cela va-t-il nous coûter » ? En théorie, tous les efforts des responsables sécurité sont focalisés sur une approche globale et normée de la protection des S.I., partant du principe qu'il est plus facile de vérifier si les méthodes de surveillance de l'application des « boulons » sont efficaces plutôt que de perdre du temps à tester la pose correcte de chaque boulon. C'est la vision ISO 27001 de la chose, certes un peu caricaturée, mais oh combien réaliste. En pratique, il semblerait que les principaux éditeurs et équipementiers espèrent imposer une optique diamétralement opposée à cette stratégie normative . Notamment en prônant une action de plus en plus microscopique de la sécurité, concentrée sur l'élément et non plus sur l'ensemble. A commencer par Microsoft, qui déplace toute notion de sécurité au niveau du composant logiciel, du pilote, du processus. Une vision que condamne notamment Peter Gutmann, un universitaire Néozélandais qui fait beaucoup parler de lui actuellement pour avoir publié « A Cost Analysis of Windows Vista Content Protection ». Sans surprise, les DRM en prennent plein leur grade, les outils de reproduction musicale ou d'images animées signés Microsoft également. Rien de très nouveau de ce coté là. On peut toutefois s'attarder sur les chapitres intitulés « Elimination of Unified Drivers » et « Denial-of-Service via Driver Revocation » qui explique comment invalider une licence Windows par le simple jeu des mises à jour de pilote et l'abandon de maintenance desdits pilotes frappés par la limite d'âge. L'on pourrait également gloser à longueurs de ligne sur la complexité croissante imposée aux administrateurs de parc, transformés en surveillants de versions de DLL -le DLL Hell, c'est plus seulement les autres-, lesquels administrateurs seront conduits à une course à la modernité qui ne dépendra plus d'un problème de performances pure, mais du bon vouloir des éditeurs : si toi pas changer carte machin, toi plus pouvoir travailler car pilote plus valide. Donc toi devoir payer. Et l'on pourrait chanter cette antienne de troufion « c'est pas d'l'intimidation, c'est d'la sécu, c'est pas du racket mais ca viendra». Le raisonnement, pour certains, dépasse, et de loin, l'aspect matériel de la chose. Dans les colonnes d'un récent numéro de CIO, Ray Ozzie , qui a définitivement pris les couleurs de Seattle, declare « In terms of managing trust boundaries, one of the huge challenges that enterprises are going to have is...managing trust between components of composite applications». et de continuer « We believe there should be significant auditing within service components-such that when you do expose a partner to certain enterprise data...you have a complete record of the kinds of things that their app did ». En d'autres termes, Ozzie explique que ce qui se pratique au niveau matériel pourrait l'être également au niveau applicatif. La gestion et la surveillance de la sécurité des applications, nul ne peut prétendre le contraire, est encore bien plus complexe qu'une simple vérification d'intégrité de driver. Si l'on peut, de prime abord, trouver séduisante l'idée d'une « certification de confiance » appliquée à chaque accessoire logiciel, on se demande comment une telle stratégie peut s'appliquer dans le cadre d'applications complexes et hétérogènes. Le seul travail de recensement est titanesque. Ansi dans le domaine des services Web, par exemple, peut-on, sans erreur, faire le compte des appliquettes et services effectuant des échanges entre machines de noyaux différents ? ou l'inventaire de programmes non nécessairement souhaités et bénis par un éditeur dominant mais nécessaires à une entreprise ?... peut-on imaginer qu'un jour, le lancement d'un logiciel soit soumis à approbation par un mécanisme tout comme serait approuvé l'entrée d'une machine distante sur un réseau comme prétend le faire un NAP ou un NAC ? NAP et NAC ne sont jamais qu'une forme un peu plus complexe d'antivirus, autrement dit un créneau simple à administrer, restreint d'un point de vue fonctionnel... et surtout dont on peut parfaitement se passer. Etendre cette idée à tout fonctionnement logiciel (autrement dit de l'approbation de confiance par le noyau) impliquerait immanquablement une « simplification » du champ d'approbation... car aucun module « trusted computing » ne peut prétendre connaitre tout ce qui s'est écrit ou s'écrira. En termes moins fleuris, cela signifie soit l'élimination pure et simple de tout programme ou service n'entrant pas dans le catalogue de l'éditeur du noyau ou du programme de protection réseau, soit la prise en charge « à la main » des exceptions d'exécution par l'administrateur, exécutable après exécutable, bibliothèque de fonction après bibliothèque de fonction. De ces deux vision, l'une est difficilement admissible, l'autre est difficilement applicable. Déjà, concepteur de programmes Open Source, éditeurs de logiciels de sécurité s'élèvent contre cette vision trop restrictive. Mais il risque d'être déjà trop tard.
