Le RGS : une bonne opportunité pour faire de la sécurité au sein des collectivités locales ?

Dans les esprits, le respect du RGS (Référentiel Général de Sécurité) est souvent cantonné  à la mise en œuvre de certificats électroniques SSL “étoilés”. Dans la réalité, il dépasse ce périmètre technique en adressant de bonnes pratiques d’organisation et de gestion de la sécurité.

Au-delà du pur objectif normatif voire légal, quels bénéfices peut-on tirer de la mise en œuvre d’une démarche d’homologation RGS ?

Tout d’abord, il nous semble important de démystifier le RGS.

Le RGS, en réalité  qu’est-ce donc ?

• Adopter une approche par les risques : Adapter la démarche et le niveau de sécurité cible en fonction des risques et du contexte.

• Formaliser une politique de sécurité globale : Formaliser le cadre général de la sécurité intégrant les objectifs de sécurité de l’organisation, la description des rôles et des responsabilités (MOA, RSSI, Comités, …) liés à la sécurité et les principes fondamentaux.

• Intégrer la sécurité dans la vie du SI et dans les projets : Se poser les bonnes questions le plus tôt possible pour éviter de mal y répondre voire de ne pas y répondre du tout.
  • Souvent impossibilité de prendre le temps d’atteindre le niveau cible avant la publication car la promotion du nouveau télé-service est déjà lancée auprès des usagers.
  • Parfois incapacité d’atteindre le niveau cible car les exigences n’ont pas été inclues dans le CCTP et donc non respectées par le prestataire en charge de la fourniture de la solution.

• Utiliser des produits et des prestataires labellisés : Un “coup de tampon” d’un tiers de référence sur un service ou une solution, c’est un gage de qualité et de confiance pour renforcer la démarche sécurité.

• Mettre en place un processus d’homologation : Un représentant de la collectivité, appelé Autorité de Qualification (AQ), doit attester formellement, en s’appuyant sur un Dossier de Sécurité, que le niveau de sécurité de l’application est conforme au niveau cible attendu.

Quels bénéfices pour la collectivité et la fonction sécurité ?

Le RGS représente une réelle opportunité pour faire de la sécurité et apporter de la valeur à la collectivité et à la fonction sécurité en :

• Accompagnant le développement de la dématérialisation et des services innovants des villes et territoires “intelligents”.

• Engageant une collaboration pérenne autour de la sécurité de l’information entre des Fonctions qui ont souvent du mal à communiquer (et manquent d’occasion de le faire), c’est-à-dire la Communication (TIC, Numérique, …), le Juridique et l’Informatique, et même entre le RSSI et les autres Services au sein de la Direction Informatique.

• Sensibilisant la Direction, les agents et même les usagers vis-à-vis des risques liés à la cybercriminalité et aux nouveaux usages.

• Contribuant à l’acculturation au concept de gestion des risques et ainsi à l’amélioration de l’image du RSSI qui est souvent vu comme “celui qui bloque” plutôt que “celui qui encadre les usages”.

Comment s’y prendre ? Nos 5 règles d’Or

Règle n°1 : Obtenir l’adhésion

Comme pour toute démarche transverse, il est indispensable, afin qu’elle aboutisse, d’obtenir l’adhésion de la Direction et des représentants des Fonctions “Communication/Numérique”, “Juridique” et “Informatique” (bien sûr).

C’est ici que le RGS, en tant que référentiel imposé par l’ANSSI et faisant écho à la Loi Informatique et Libertés bien connue de tous (le mot-clé “CNIL” résonne plutôt bien), permet plus facilement (ou pour être plus réaliste, moins difficilement), de fédérer diverses fonctions autour d’une démarche Sécurité.

Règle n°2 : S’assurer que la règle n°1 est bien respectée

Être sûr que la règle n°1 sera respectée en s’appuyant sur vos relais internes (Correspondant Informatique et Libertés, Chargé de Mission e-administration, DGA, …) au moyen de quelques sessions de présentation du RGS et de ses bénéfices pour la collectivité.

En fonction de votre organisation (et des possibilités offertes), identifier qui sera votre Autorité de Qualification : Élu référent informatique, DGS, DGa, …

Règle n°3 : Identifier les applications soumises au RGS

Réaliser un inventaire des applications soumises au RGS déjà et à venir.

Règle n°4 : Intégrer de la sécurité dans les projets

Définir, en collaboration avec les équipes projet technique et étude, une démarche d’intégration de la sécurité dans les projets (ISP) s’appliquant aux projets RGS et également aux autres projets (c’est-à-dire la grande majorité cf règle n°3). Intégrer dans la démarche ISP un volet Analyse de risques pragmatique et généralisable.

Règle n°5 : Expérimenter sur un projet pilote

Expérimenter la démarche sur un ou deux projets pilotes en choisissant un projet “phare” pour faciliter la règle n°1.

Ce qu’il faut en retenir

Le RGS, plus qu’une simple obligation, permet de donner une véritable impulsion  dans la démarche globale de sécurité et de fédérer différentes Directions au sein de la collectivité. Avec une démarche pragmatique, la mise en œuvre est tout à fait possible.