L'idée de rendre les éditeurs de logiciels responsables des failles de sécurité de leurs produits fait son chemin. Des propositions sont faites en ce sens par différents groupes de pression aux Etats-Unis. La semaine dernière, le gouvernement américain les a même écoutés. Sans paraître totalement convaincu pour autant...

au sommaire

    En bon pèlerin, Richard Clarke bat la campagne américaine depuis plusieurs semaines. Pour ce responsable du comité chargé de définir le programme de cyber-défense des Etats-Unis (PCIPB), il s'agit avant tout d'un voyage d'étude. Il recueille en chemin les avis d'experts, d'universitaires et d'industriels sur la meilleure manière d'aider son pays dans sa lutte contre le cyber-terrorisme. Son rôle n'est pas tant de juger de la pertinence de la menace (le FBI sait très bien brandir seul l'épouvantail du cyber-terrorisme) que de trouver des parades.

    Parti avec la ferme conviction que l'Etat doit laisser le marché réguler seul les problèmes de sécurité et se débarrasser des incompétents, il est forcé de reconnaître aujourd'hui que ce processus Darwinien est bien plus long que prévu. Et aussi qu'il concerne toute l'industrie et non juste MicrosoftMicrosoft, qui apparaît finalement n'être que le chef de file de cette marche peu glorieuse.

    Une intervention de l'Etat est envisagée

    Richard Clarke reconnaît ainsi, à mi-parcours, que son comité a reçu de nombreuses demandes, y compris de la part du secteur privé, en faveur d'une solution d'Etat à ce problème endémiqueendémique. Et il admet que, peut-être, finalement, une nouvelle législation pourrait bien forcer les éditeurs de logiciels à livrer des produits fiables. L'arsenal qui lui est proposé pour cela tourne le plus souvent autour de deux propositions : rendre les éditeurs responsables devant la justice des failles de leurs produits, ou les obliger à respecter des critères de sécurité minimaux lors de leur création.

    Mais rien n'est décidé que déjà ces deux propositions soulèvent leur lot de questions.

    Ainsi, si la première idée est retenue, il sera alors nécessaire de définir ce qui est réellement une faille de sécurité, et entrer dans des débats d'experts après chaque intrusion. Contre quel fabriquant se retourner en effet lorsqu'une attaque a exploité une série de failles en cascade, chacune n'étant pas suffisante pour compromettre le système ? Et quid des logiciels libres ? Qui serait rendu responsable de leurs défauts ? Les obstacles juridiques sont manifestement trop nombreux pour voir une telle législation naître rapidement.

    Un problème de standards

    Quant à la seconde solution évoquée, privilégiant une contrainte à priori plutôt qu'une punition à posteriori, elle pose le problème de la définition de ces critères de sécurité minimaux. Les principaux navigateurs ne parviennent toujours pas à afficher à l'identique la même page web après huit ans d'existence, la création d'un organisme fédérateur mondial (le W3C) et d'un standard clairement défini (HTMLHTML). Autant dire que pour la sécurité, la tâche semble mal engagée. Sauf, peut-être, à s'appuyer sur les travaux du groupe ISOISO, qui a déjà travaillé sur la sécurité (norme ISO 17799)... et connaît toute la difficulté d'une telle entreprise de standardisation !

    On comprend mieux dans ces conditions pourquoi, bien que n'excluant plus une législation spécifique, Richard Clarke espère encore que le marché pourra se débrouiller seul... sans engager la responsabilité du gouvernement.

    En attendant, cela signifie pour nous, utilisateurs, qu'à l'ouest, il n'y aura rien de nouveau avant longtemps.