Politique de sécurité de l'information : que faut-il y mettre ?

La Politique de sécurité est un document majeur qui exprime la volonté de la Direction Générale en matière de sécurité de l'information.

Ce document "met en musique" le management de la sécurité. Autant bien rédiger la partition ; zoom sur les clauses recommandées.

photo : Mike Castro Demaria by Unsplash

Qu'est-ce que la sécurité de l'information ?

Rappeler de quoi il s'agit : protéger la confidentialité, l'intégrité et la disponibilité des informations. Pouvoir tracer toutes les actions dessus. C'est le minimum à exiger.

Pour qui faisons nous cela ?

Il faut définir simplement quels seront les bénéficiaires de la démarche sécurité que l'on veut lancer : les clients ? les usagers des applications informatiques (internes ou pas) ? des partenaires qui se connectent à notre SI ? les administrateurs des données et systèmes ? le grand public ? l'Etat ?

Il faut de plus reconnaître les attentes et exigences en matière de sécurité de l'information émanant de ces parties intéressées.

Selon les "parties intéressées" définies, ce qu'il y a à faire va varier.

Sur quel périmètre porte la démarche ?

La démarche de mise en sécurité et de son maintien porte-t-elle sur toute l'informatique ? toutes les données ? tous nos moyens IT ? la salle technique ? le data center ? y compris la partie outsourcée chez Microsoft Azure ou AWS ? ou seulement certaines applications (liées au paiement par exemple) ? 

Ces points sont très importants à lister. Il faut aussi penser à tout ce qui est sous-traité, même si on a tendance à l'oublier (en mode SaaS par ex. Office 365). On voit aussi qu'il faut se préoccuper de la sécurité de ce qui est "hors les murs" mais contient nos données.

Rappeler les contraintes réglementaires

Dans une politique il est bon de rappeler ce qui va encore mieux en le disant : nous sommes soumis à des contraintes réglementaires diverses en sécurité de l'information, d'origine européenne, étatique ou collégiale. RGPD, Solvency ou Bâle III sont des exemples. 

Définir une entité en charge de l'identification et du suivi de ces aspects.

Souligner l'approche risque : identification et traitement

On ne fait pas de la sécurité pour le plaisir. On met en place des mesures de protection pour prévenir ou corriger les risques. Il n'est pas de sain management sans une connaissance efficace et éclairée des risques en sécurité de l'information. Ni sans vérifier que les mesures en place réduisent bien les risques.

Qui est "propriétaire des risques" : le DSI ? les métiers sur leur partie ? la DG ? Comment va-t-on identifier, analyser et évaluer les risques de sécurité ? Qui valide ? avec quelle méthode ? Qui décide du traitement des risques ?

Le traitement des risques consiste à mettre en place des mesures de sécurité visant à protéger confidentialité, intégrité et disponibilité de l'information. 

Ces deux étapes "appréciation" et "traitement" des risques de sécurité sont au cœur du document de politique. Les responsables en charge doivent être déterminés dans le document. Une validation générale et régulière est à prévoir (l'homologation exigée par la Politique de SI de l'Etat) ou exigée par la norme ISO 27001.

La Direction doit fixer des objectifs

Des objectifs de sécurité clairs et vérifiables sont à mettre dans la politique ; ce n'est pas le plus simple à faire. 

Cela peut être :

• général : "assurer la confidentialité, l'intégrité et disponibilité des données"
• sur un événement visé : "être certifié ISO 27001 dans les 18 mois"
• des objectifs de couverture du périmètre : "avoir des procédures pour apprécier les risques sur tous les services métiers" ou "développer une culture de la sécurité sur tel périmètre"
• des objectifs d'efficacité : "réduire le nombre d'incident de sécurité"  
• des objectifs de satisfaction : "ne pas avoir de plaintes clients"
• des objectifs de conformité à un référentiel : "ne pas avoir de non-conformité sur tel périmètre", ...

Ces objectifs doivent être datés, atteignables et liés aux enjeux métiers de l'entreprise.

La mise à disposition de ressources 

Dans la politique il est bon (mais difficile) de rappeler que des moyens sont mis à disposition au moins sur les points suivants :

• la sensibilisation des divers personnels à la sécurité et à la politique
• la formation des personnels clés en sécurité
• les ressources techniques (et donc souvent un budget ou des codes projets ouverts)
• la communication sur la sécurité en temps normal et en temps de crise 
• la documentation (des procédures, processus, directives, ...)

Rappeler qui est en charge de quoi en matière de ressources impliquées dans la sécurité est essentiel. Le RSSI est rarement le dépositaire de toutes les ressources.

Mettre en place les mesures de sécurité

Suite à appréciation et traitement des risques, des mesures de sécurité sont à compléter ou à mettre en place en cas d'absence. 

Divers textes de référence nous donnent des listes de mesures "prêtes à l'emploi" (normes ISO, Politiques de l'Etat par exemple). En général on trouve les sujets suivants à aborder dans la politique au moins pour indiquer qui doit traiter (ex à partir de l'ISO 27001 Annexe A) :

• la sécurité des RH : charte informatique, confidentialité, vérification à l'embauche, durant le contrat et en cas de mutation, terminaison ...
• la connaissance du parc informatique géré et exploité : quels matériels ? quels systèmes ? où ? sous quelle responsabilité ? pouvoir faire le lien avec les incidents et vulnérabilités aux attaques ou à l'obsolescence ?
• les accès logiques autorisés pour tous types d'usagers et de gestionnaires, leur bien fondé, leurs limites et leur revue régulière
• le chiffrement nécessaire et ses règles d'usage et de gestion
• la sécurité des accès physiques à l'information, aux serveurs et routeurs réseau etc.   et donc aux locaux techniques, salles de brassage et bureaux, systèmes de sécurité type badgeuses et gestion des badges
• la sécurité en exploitation (surveillance, protection des codes en exécution, sauvegardes et restauration des données, correction des vulnérabilités techniques en exploitation, mise à niveau de sécurité, détection d'intrusion, traçabilité des actions des administrateurs à risques, logs et protection, etc.)
• la sécurité du réseau (paramétrage des ports, segmentation en sous-réseaux, restriction des droits en administration, approches "zero trust" ou VPN, etc.)
• sécurité des développements pour éviter les risques de vulnérabilités et d'attaques possibles du code, sécurisation des compilations et des accès aux tests, fiabiliser le passage en production, tracer les interventions des développeurs en correction de bogues ou en urgence en production, etc.
• sécurité des fournisseurs qui peuvent avoir accès à votre information (mainteneurs de matériels, recycleurs de disques durs, sociétés de nettoyage, ...)
• la gestion des incidents et la culture de la déclaration réactive et efficace pour la maîtrise des incidents et de leur correction
• la continuité de la sécurité en cas d'interruption plus ou moins forte (à relier à une approche PCA/PRA), la résilience des moyens de sécurité actifs
• la conformité aux réglementations diverses et aux bonnes pratiques techniques

Chacun des points précédents peut (doit) faire l'objet d'un document descriptif de la politique d'application détaillée. Dans la Politique générale, on citera ces points en indiquant qui en est responsable dans l'organisation.

La gouvernance générale de la sécurité

Une organisation est à créer, comportant essentiellement un(e) RSSI et des correspondants sécurité là où il le faut. Une comitologie est à mettre en place. Ceci est à décrire à part mais à mentionner.

De plus, il est indispensable que la Direction demande d'accompagner la démarche de management de la sécurité sur trois points :

• mettre en place des indicateurs clés de performance (dans la politique on désigne au moins qui s'en occupera : le RSSI par exemple) 
• mettre la démarche sécurité sous audit : demander un programme d'audits internes réguliers sur le sujet
• faire une revue de direction régulière pour avoir un levier sur le réel et réorienter la démarche si besoin

La culture de l'amélioration continue

Dernier aspect, apport fondamental des normes de systèmes de management ISO : on cherche toujours à faire mieux.

Une attention particulière est portée par la DG qui doit d'abord passer par le management intermédiaire (mais aussi via l'audit interne par exemple et au travers du RSSI) sur :

• les résolutions d'incidents de sécurité
• les non-conformités par rapport à la présente politique
• toute idée d'amélioration continue.

Cette culture de l'amélioration vise aussi à empêcher les effets de sclérose ou d'empêchement d'innover qui sont souvent reprochés aux démarches "normalisantes".

Voici rapidement brossé ce que peut contenir une Politique de sécurité de l'Information.

=§=