Un nouveau projet de Directive sur la sécurité informatique

1) Un objectif louable et ambitieux

Le projet de directive a un objectif clair, puisque le texte tend à mettre en place « des mesures destinées à assurer un niveau élevé commun de sécurité des réseaux et de l’information dans l’Union« . On ne peut que souscrire aux objectifs tant il est vrai qu’on se lasse d’être spectateur de la récurrence des atteintes aux systèmes d’information. Les premiers mots du texte d’ailleurs témoignent assez convenablement de ce constat :

La directive proposée vise à assurer un niveau commun élevé de sécurité des réseaux et de l’information (SRI). Aussi faut-il accroître la sécurité de l’internet et des réseaux et systèmes informatiques privés sur lesquels reposent les services dont dépend le fonctionnement de notre société et de nos économies« .

Heureux d’avoir attendu 2013 pour s’en soucier, le texte toutefois ne vise qu’un nombre limité d’acteurs (les opérateurs d’infrastructures critiques, les principaux prestataires de services de la société de l’information, ainsi que les administrations publiques), mais qu’importe, on note l’effort déjà substantiel et symptomatique de progrès.

2) Une effectivité très discutable

Sitôt le constat effectué, on se demande alors légitimement comment le texte va parvenir à l’objectif posé ? On pense évidemment immédiatement à la responsabilité spécifique des éditeurs de logiciels et l’obligation de patcher les codes défectueux, qui serait sans doute la mesure la plus intéressante à explorer en la matière, mais le projet passe sur la question. A part une disposition qui va susciter l’ire de nombreux professionnels (voir point 3 plus bas), le projet est d’une construction bureaucratique exemplaire dont le papier reste l’arme la plus utilisée ; à l’exception peut-être de la notification des failles de sécurité que le texte refaçonne pour la troisième fois dans une obligation encore plus générale.

La notification des incidents de sécurité, v. 3.0

Globalement, la mesure phare du projet reste la notification des violations de sécurité que la Directive cherche à étendre autant que possible.

L’obligation de notification des incidents de sécurité informatique est très vague et imprécise

Grosso modo : on reprend ce qui se fait déjà en matière de télécommunication (v. 1.0), et ce qui va se faire en matière de protection des données personnelles (voir le projet de règlement européen – v. 2.0 – si vous ne connaissez pas c’est le bon moment pour vous penser à une formation CIL), et on étend cela à qui pourra (v. 3.0). A défaut d’imagination, cela permet de remplir un peu de papier, mais en beaucoup plus vague cependant, car le texte prévoit que (art. 14) :

Les États membres veillent à ce que les administrations publiques et les acteurs du marché notifient à l’autorité compétente les incidents qui ont un impact significatif sur la sécurité des services essentiels qu’ils fournissent.

Le moins que l’on puisse dire c’est que la notion est déjà vouée à interprétation ! On s’interroge sur ce que seront des incidents ayant « un impact significatif » sur la SSI. Une diffusion de quelques millions de numéros de cartes bancaires sur Internet ? Ca se discute : les numéros sont diffusés, mais la faille a été comblée immédiatement. Cela n’a donc plus aucun impact sur la sécurité, puisque la faille n’existe plus. Bon on caricature certainement, mais il est déjà certain que l’ANSSI n’aura pas la même doctrine qu’une organisation victime de failles de sécurité… Il est regrettable à ce titre que les rédacteurs du texte n’aient pas édicté de critère plus strict d’appréciation.

En tout état de cause le problème de cette approche est que l’on se retrouve donc avec une double notification. La première sera à faire à la CNIL, lorsque le projet de règlement sera passé (ou si l’entreprise est un opérateur de communications électroniques, il lui advient de le faire dès à présent), et une seconde notification à l’Autorité nationale de sécurité informatique. Le schéma est un peu kafkaïen, au point que le projet de Directive tente tant bien que mal à palier la problématique, précisant que les « États membres doivent mettre en œuvre l’obligation de notifier les incidents de sécurité d’une manière qui réduise au minimum la charge administrative ». Nous voilà évidemment rassurés…

Les autres mesures

Au passage le texte ajoute quelques mesures dignes de la bienséance bureaucratique, telles que :

  • l’obligation pour les Etats de prendre des mesures afin d’assurer un haut niveau de sécurité informatique (art. 5) ;
  • l’établissement de plans de sécurité au niveau national (art. 5) ;
  • la mise en place d’Autorités nationales de sécurité informatique (art. 6) et de CERT (art. 7) ainsi que des réseaux de coopération (art. 8) dont on apprend que les échanges seront sécurisés (art. 9).

Rien de vraiment nouveau sur le sol français. Aucune mesure opérationnelle efficace, juste l’expression d’une technico-bureaucratie qui cherche à occuper l’espace.

3) Une mesure contraignante inquiétante

Au-delà des procédures papier, une disposition du texte retient toutefois l’attention : en effet, le projet de Directive prévoit que les autorités pourront exiger des entreprises (et administrations) de subir un audit de sécurité obligatoire. L’article 15 impose qu’elles :

(a)  fournissent les informations nécessaires pour évaluer la sécurité de leurs réseaux et systèmes informatiques, y compris les documents relatifs à leurs politiques de sécurité ;

(b)  se soumettent à un audit exécuté par un organisme qualifié indépendant ou une autorité nationale et mettent les résultats de cet audit à la disposition de l’autorité compétente.

Les États membres veillent à ce que les autorités compétentes aient le pouvoir de donner des instructions contraignantes aux administrations publiques et aux acteurs du marché.

Ces obligations sont pour le moins dérangeantes.

D’abord les entreprises devront communiquer aux administrations l’ensemble des informations relatives à leur sécurité informatique et toute information nécessaire pour évaluer la sécurité de leurs systèmes, comme par exemple l’ensemble de leurs codes sources dans le cadre d’applications SAAS.

A l’image du contrôle fiscal la directive prévoit un audit de sécurité obligatoire pour les entreprises

Autant dire qu’il en est terminé de la confidentialité de ses codes sources à partir du moment où l’application est à disposition du public. On se demande en vertu de quoi l’Administration va s’arroger le droit de contrôler la sécurité de quiconque lui plaira et se faire communiquer l’ensemble des informations telles que les noms d’utilisateurs, les mots de passe utilisés, etc. Cela semble pour le moins excessif !

Ensuite, se faire réaliser un audit implique plusieurs éléments : d’une part on s’interroge quant aux coût supportés par cet audit ? Faudra-t-il que l’entreprise supporte ces coûts ou ceux-ci seront-ils supportés par l’Administration ? Vu les finances de l’Etat la réponse est déjà acquise : les entreprises payeront ! D’autre part, on se demande quels seront les critères de sélection des personnes victimes objet de ces audits de sécurité ? On pressent déjà les dérives possibles de cette nouvelle arme administrative, qui sera doublée évidemment de sanctions en cas de réticence (art. 17).

Enfin, la dernière interrogation tient à la possibilité pour l’Administration d’accéder aux systèmes d’informations de la personne auditée. Cette dernière sera-t-elle tenue de mettre à disposition ses locaux, son infrastructure et l’ensemble de ses codes source et donc de sa propriété intellectuelle à l’auditeur ? Qu’en est-il des garanties de confidentialité ? Aucune n’est prévue par le texte ! Encore une fois : disproportionné. Il est totalement louable d’exiger des minima en matière de sécurité informatique, mais le faire sans préciser ces éléments essentiels est pour le moins problématique. Le projet de Directive manque ici de fournir des garanties essentielles à ce titre et laisse craindre d’importantes dérives dans sa forme actuelle.

Conclusion

En l’état le projet de Directive a de quoi inquiéter et alerter en raison de sa rédaction vague et imprécise. Imposer des audits de sécurité assortis de sanctions importantes (art. 17), sans guère offrir de garanties est attentatoire aux libertés fondamentales dans une société démocratique car il présage la possibilité pour une autorité administrative d’accéder sans limite aux domicile et aux biens de personnes privées. Une telle posture est déjà fort heureusement réfutée en droit français.

Reste à voir l’évolution du projet et sa transposition dans notre droit national. On note que le texte n’est même pas encore élaboré que déjà on pense à la QPC…

Affaire à suivre…

Dites-nous si vous pensez que ce texte est raisonnable et quelles seraient les mesures de sécurité que vous imposeriez ?

Thiébaut Devergranne
Thiébaut Devergranne
Thiébaut Devergranne est docteur en droit et expert en droit des nouvelles technologies depuis plus de 20 ans, dont 6 passés au sein des services du Premier Ministre. En savoir plus

Ils nous ont fait confiance

logo Deloitte
logo starbucks
logo orange bank
logo vinci
logo nokia
logo sanofi
logo sncf
Automatisez votre conformité RGPD
Economisez-vous des semaines de travail avec Legiscope logiciel de gestion de la conformité RGPD
VOS CGV (gratuites)