Début janvier 2011, une affaire de divulgation d’informations, concernant le fonctionnement interne du conseil général des Bouches du Rhône, a défrayé la chronique. A l’image du fameux site Wikileaks, un internaute a pris l’initiative de créer un site « boite aux lettres », où d’autres internautes pouvaient en toute sécurité « poster » des documents confidentiels, censés éclairer des pratiques illicites sur les appels d’offres et tout autre sujet « chaud ». Très rapidement, le responsable du site a été identifié : il ne se cachait d’ailleurs pas vraiment. Il s’agissait d’un informaticien du CG13, qui a fait l’objet depuis d’une mesure disciplinaire.

Fin de l’histoire. Du côté de Marseille, peut-être. Mais la question de la sécurité des systèmes d’informations des collectivités a été posée. En effet, la plupart des documents exposés sur le site Wikileaks 13, avaient circulé dans l’informatique du Conseil Général. De quoi réveiller des élus généralement assez peu concernés par la sécurité... quand elle n’est qu’informatique ? Pas tout à fait, si l’on en croit Francis Kuhn, directeur général du Sictiam, le syndicat qui gère la plateforme de mutualisation informatique de plusieurs dizaines de communes des Alpes Maritimes – plus quelques unes dans les départements avoisinant, notamment le Var. « Nous n’avons pas noté un afflux notable de questions de nos élus concernant la sécurité après cette affaire ».

Il y aurait pourtant beaucoup à faire, selon le technicien. « En quelques années, le déploiement rapide de l’informatique dans les collectivités a contribué à fragiliser l’édifice. Il n’y a plus de schéma directeur depuis cinq ou six ans, les choses évoluent trop vite. Les règles d’utilisation ne sont plus posées, en particulier concernant la circulation des documents, leur degré de confidentialité, et les droits de consultation qui s’y raccrochent ».

Le RGS, une bonne initiative, mais beaucoup de travail à mener

L'informatique n'est pas responsable de tous les maux. Elle en serait plutôt le révélateur, dans la mesure où, en outillant de nombreux processus, elle en révèle les faiblesses, notamment en matière de confidentialité. Il n’empêche que cette « insécurité » inédite est sur la pente ascendante. « Jusqu’à maintenant, les réponses ont été sporadiques, à base d’antivirus, de mots de passe, etc. Il est temps de poser notre sac et de considérer le problème avec méthode ».

Ce qui tombe bien en termes de calendrier. Car le Référentiel Général de Sécurité (RGS), institué par l’ordonnance du 8 décembre 2005, vient de faire, le 6 mai 2010, l’objet d’un arrêté de la part du premier ministre. Sa gestation a certes pris du temps, de la même manière que la maturation du RGI (pour l’interopérabilité) ou le RGAA (pour l’accessibilité numérique). Mais l’originalité du RGS tient aux exigences fortes de mise en conformité qui l’accompagnent. En effet, concrètement, depuis l’automne dernier, plus aucun système d’information ne peut être mis en route dans une administration, sans être homologué RGS.

Or ce référentiel n’est pas, pour ce qui est de la simplicité d’utilisation, au niveau du tournevis. Sa partie la plus opérationnelle est celle qui décrit des règles techniques à respecter pour obtenir certains niveaux de sécurité lors d’opérations telles que la signature électronique. Mais le vrai challenge, pour les administrations, est l’obtention de l’homologation de systèmes d’information, autrement dit d’un ensemble d’outils techniques et de procédures.

Alors certes, le RGS est proposé avec une méthode d’évaluation des risques (Méthode Ebios 2010) et des fiches d’expression, mais il y a loin de la coupe aux lèvres. Le Sictiam, qui s’est rapproché dès le début 2010, de l’ANSSI (l’agence nationale pour la sécurité des systèmes d’information), chargée par le gouvernement de diffuser le RGS et d’assister les administrations, en a fait l’expérience. « L’existence de ce référentiel est une très bonne chose, affirme avec force Francis Kuhn. Mais il faut prévoir beaucoup de temps pour l’analyse des risques, car les méthodes proposées sont complexes pour le néophyte. Nous avons du mobiliser un collaborateur à temps plein ».

Quel risque pour les élus ?

Le Sictiam a promis, lors du dernier congrès de la FedISA, de faire profiter les autres collectivités de son investissement, en proposant des fiches standardisées d’analyse des risques, ce qui permettra de travailler par comparaison plutôt que de tout redécouvrir. « Il y a des risques qui sont communs à toutes les situations, la vraie différence se fera surtout au niveau des organigrammes, et de la définition des responsabilités dans la circulation de documents par exemple ».

Cette analyse effectuée, il faudra ensuite investir pour atteindre le niveau de sécurité requis pour l’homologation. La partie la plus simple ? A voir. Les échanges risquent d’être dantesques entre les DSI qui présenteront la facture, les DGS qui voudront limiter les dépenses, et les maires qui assumeront le risque juridique. Un risque encore théorique, souligne Francis Kuhn, puisque l’échelle des sanctions n’est pas connue. Il n’empêche que l’arrêté d’homologation RGS étant public, l’élu devrait s’inquiéter de plus en plus de la sécurité des systèmes d’information sous sa responsabilité. Le directeur du Sictiam pense néanmoins que ce sont surtout les appels d’offres qui vont faire bouger les lignes : « depuis quelques mois, les fournisseurs ne peuvent plus proposer de réponses qui sortent du cadre du RGS. Du coup, ils mettent une grosse pression sur les collectivités pour qu’elles précisent les attentes dans les dossiers ».

Le RGS, ce qu’il faut savoir :

Le référentiel général de sécurité (RGS), a été prévu par l’ordonnance no 2005-1516 du 8 décembre 2005. La version 1.0 du RGS, résultat d’un travail conjoint entre la Direction générale de la modernisation de l’État (DGME) et l’Agence nationale de la sécurité des systèmes d’information (ANSSI, est en vigueur depuis un arrêté du Premier ministre en date du 6 mai 2010. Celle-ci est le Ce référentiel fixe, selon le niveau de sécurité requis, les règles que doivent respecter certaines fonctions contribuant à la sécurité des informations, parmi lesquelles la signature électronique, l'authentification, la confidentialité ou encore l'horodatage. Les règles formulées dans le RGS s’imposent et sont modulées en fonction du niveau de sécurité retenu par l'autorité administrative dans le cadre de la sécurisation des services en ligne dont il est responsable.

En complément à ces règles, le RGS contient des bonnes pratiques en matière de sécurité des systèmes d'information (SSI), afin de guider les autorités administratives et les prestataires de services qui les assistent dans les choix qui se présentent à eux en matière de SSI. Le RGS apporte également des éclairages nécessaires sur la marche à suivre pour prendre en compte pleinement les dispositions réglementaires, en particulier concernant l'analyse de risques et l'homologation de sécurité d'un système d'information. Source : Wikipédia

Plus d’information sur le site de l’ANSSI : http://www.ssi.gouv.fr/site_rubrique57.html