Découvrez ce que tous les entrepreneurs devraient savoir sur leur responsabilité juridique et cliquez ici !

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

On n’en finit plus avec la sécurité informatique. securiteOn a à peine commencé à se préparer à gérer la future obligation de notification des violations de la sécurité des données personnelles, que déjà la réglementation prévoit l’extension de cette obligation. Le déluge vient de Bruxelles avec un nouveau projet de Directive qui vise spécifiquement à renforcer la sécurité des systèmes d’information. L’idée générale du texte est de renforcer le niveau de sécurité informatique au sein des Etats membres. Juste cause, et belle ambition (1) ! Reste qu’en pratique l’utilité du texte laisse à désirer (2) et celui-ci prévoit des dispositions inquiétantes d’imprécision comme cette future obligation de se faire faire un audit de sécurité par l’Autorité Nationale de Sécurité des Systèmes d’Information, qui s’imposera à la manière du contrôle fiscal (3).

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 ?

2 comments… add one

  • J’ai eu l’occasion de collaborer à de nombreux projets en organisation et en informatique comme manager de projets (y compris architecture SI, PCA/PRA) et consulting « risques » au sens balois.

    On peut imaginer nombre de règlements, normes et méthodes. Cependant, les principes élémentaires de mitigation des risques ne sont pas bien maîtrisé à ce jour. Quelques exemples vécus :
    1) Des dossiers d’instructions (personnes physiques et morales) avec des documents pouvant servir de détournement d’identité se sont trouvés dans les poubelles « normales » au lieu des récipients dédiés au destructeur de documents.
    2) Faute d’avoir prévu un système de backup pour l’impression de formules (lettres-chèques de plusieurs dizaines à centaines de milliers d’Euros), le service a imprimé sur imprimante « normale », dans le couloir avec les formules dans le bac et sans surveillance. De plus, la vieille application étant difficilement maintenable, les chèques sont édités via « EXCEL » !!!
    3) Cela peut être aussi délibéré, où le système informatique ne respecte pas la 97/02 concernant la saisie de date de naissance pour l’octroi de crédits… Afin d’en faciliter l’obtention.
    4) Un « génie » des maths & stats pestait sur le calcul d’un écart-type demandé par son patron (open space). Curieux et souhaitant lui venir en aide, son ET était démeusuré. Je lui posait la question sur la nature des données (colonne Excel dont le titre était un code abscons). Il ne connaissait ni la nature ni si la population avait été soigeusement sélectionnée!
    5) En pilotage informatique, j’ai rarement vu (en France) un planning réellement calculé (ABC/ABM, COCOMO, FPA, …). Soit il existe un planning « pour faire joli », soit il n’en existe pas du tout même sur des projets d’envergure.

    Je pourrais écrire un livre …

    Donc avant de mettre en place de nouvelles réglementations, faut-il maîtriser celles en place. Encore faut-il avoir les ressources aux endroits nécessaires. Malheureusement le contrôle permanent et les risques opérationnels sont les parents pauvres des institutions bancaires.
    En informatique, je vois des demandes de « Directeur de Projets » avec 2 à 5 ans d’expérience !

    A quand les investissements dans ces domaines et quels pouvoirs effectifs pourra-t-on donner aux RO et CP (MOA) ?
    A quand une véritable maîtrise méthodologique & opérationnelle des processus de pilotage des projets SI ?

    Tout cela coûte cher. La prévention coûte cher… Les défaillances plus chères encore.

    Patrick

    Reply
    • Merci pour votre commentaire. Effectivement je pense que ce type de texte va susciter d’importantes difficultés pratiques, qui ne sont pas du tout maîtrisées par le régulateur à ce stade. Dommage une étude mieux faite du contexte aurait permis d’appréhender ces problématiques…

      Reply

Leave a Comment