Cependant, l’idéal est de la faire valider par la direction générale. Cela peut paraître
surprenant de faire signer un document très technique à la direction. Pourtant, cela a du
sens. En effet, une signature de la direction générale montre son engagement dans la
démarche de sécurité des SI. Elle permet aussi de rendre opposable ce document à toute
l’organisation. Aussi le RSSI peut-il opposer la PSSI à toute direction métier tentée de
déployer par elle-même des dispositifs informatiques.
Points à aborder
Si les chartes utilisateur sont généralement très similaires d’un organisme à l’autre, il en
va différemment des PSSI. En effet, elles reflètent directement les priorités marquées par
le RSSI. Ainsi, le responsable sécurité mettra dans la politique tout ce qui lui tient à
cœur. On retient généralement les points suivants.
Rappel du contexte : commencer par évoquer brièvement le contexte de l’entreprise
et ses enjeux en matière de sécurité.
Sécurité des RH : rappeler l’existence d’une charte destinée aux utilisateurs. La PSSI
doit explicitement dire que l’utilisateur est tenu de la respecter.
Sécurité physique : préciser que l’accès aux zones sensibles doit être protégé par
badges, qu’un processus formel d’attribution des badges doit être respecté. Par
ailleurs, on peut ajouter que les serveurs doivent être hébergés dans des salles
machines équipées dans les règles de l’art (air conditionné, alimentation électrique,
détection d’incendie, etc.).
Contrôle d’accès : spécifier que l’accès aux données doit être authentifié et limité au
droit d’en connaître de l’utilisateur. Cette clause a pour but d’obliger les développeurs
à mettre en place des dispositifs en ce sens. Il est aussi utile de rappeler que des
processus formels d’attribution des droits doivent être respectés et que des revues
régulières sont organisées.
Exploitation des SI : préciser que les équipements doivent être protégés par un
antivirus, que les correctifs de sécurité doivent être appliqués et que les mots de passe
doivent être de bonne qualité impose de bonnes pratiques à l’exploitation.
Sauvegardes : si les sauvegardes sont réalisées, les restaurations sont rarement
testées. Une clause imposant des tests périodiques de restauration est tout à fait
souhaitable.
Postes de travail : rappeler que les postes doivent être sécurisés oblige les équipes à
maintenir cette sécurité dans la durée.
Communications : maintenir un schéma réseau à jour, interdire les flux directs entre
l’intérieur et l’extérieur, protéger les liaisons en fonction de leur sensibilité sont des
clauses incontournables. On peut aussi ajouter que l’attribution des accès distants au
SI est réglementée et soumise à des procédures.
Sécurité dans les projets : imposer la sécurité dès le début des projets aide à
généraliser les bonnes pratiques. Des dossiers projets présentent les enjeux de sécurité
en matière de flux réseau, d’authentification, ou de stockage. Les profils de comptes
doivent aussi être étudiés à ce stade.
Gestion des tiers et sous-traitance : aborder cette question dans la PSSI aide à
surprenant de faire signer un document très technique à la direction. Pourtant, cela a du
sens. En effet, une signature de la direction générale montre son engagement dans la
démarche de sécurité des SI. Elle permet aussi de rendre opposable ce document à toute
l’organisation. Aussi le RSSI peut-il opposer la PSSI à toute direction métier tentée de
déployer par elle-même des dispositifs informatiques.
Points à aborder
Si les chartes utilisateur sont généralement très similaires d’un organisme à l’autre, il en
va différemment des PSSI. En effet, elles reflètent directement les priorités marquées par
le RSSI. Ainsi, le responsable sécurité mettra dans la politique tout ce qui lui tient à
cœur. On retient généralement les points suivants.
Rappel du contexte : commencer par évoquer brièvement le contexte de l’entreprise
et ses enjeux en matière de sécurité.
Sécurité des RH : rappeler l’existence d’une charte destinée aux utilisateurs. La PSSI
doit explicitement dire que l’utilisateur est tenu de la respecter.
Sécurité physique : préciser que l’accès aux zones sensibles doit être protégé par
badges, qu’un processus formel d’attribution des badges doit être respecté. Par
ailleurs, on peut ajouter que les serveurs doivent être hébergés dans des salles
machines équipées dans les règles de l’art (air conditionné, alimentation électrique,
détection d’incendie, etc.).
Contrôle d’accès : spécifier que l’accès aux données doit être authentifié et limité au
droit d’en connaître de l’utilisateur. Cette clause a pour but d’obliger les développeurs
à mettre en place des dispositifs en ce sens. Il est aussi utile de rappeler que des
processus formels d’attribution des droits doivent être respectés et que des revues
régulières sont organisées.
Exploitation des SI : préciser que les équipements doivent être protégés par un
antivirus, que les correctifs de sécurité doivent être appliqués et que les mots de passe
doivent être de bonne qualité impose de bonnes pratiques à l’exploitation.
Sauvegardes : si les sauvegardes sont réalisées, les restaurations sont rarement
testées. Une clause imposant des tests périodiques de restauration est tout à fait
souhaitable.
Postes de travail : rappeler que les postes doivent être sécurisés oblige les équipes à
maintenir cette sécurité dans la durée.
Communications : maintenir un schéma réseau à jour, interdire les flux directs entre
l’intérieur et l’extérieur, protéger les liaisons en fonction de leur sensibilité sont des
clauses incontournables. On peut aussi ajouter que l’attribution des accès distants au
SI est réglementée et soumise à des procédures.
Sécurité dans les projets : imposer la sécurité dès le début des projets aide à
généraliser les bonnes pratiques. Des dossiers projets présentent les enjeux de sécurité
en matière de flux réseau, d’authentification, ou de stockage. Les profils de comptes
doivent aussi être étudiés à ce stade.
Gestion des tiers et sous-traitance : aborder cette question dans la PSSI aide à