facile à mettre en œuvre. La tâche est plus complexe pour les serveurs et les bases de
données, car les exploitants redoutent des régressions de service, si bien que le projet
n’avance que très lentement. Enfin, il reste les équipements d’infrastructure que l’on
oublie souvent : hyperviseurs de machines virtuelles, contrôleurs de baies de disques,
cœurs de réseau, répartiteurs de charge, etc. Comment avoir la certitude que l’on n’a
rien oublié ? Or, tant qu’un élément clé du SI dispose d’un mot de passe trivial, le SI
est en danger.
Serveurs : la sécurisation des serveurs (dont le changement de mots de passe n’est
qu’un des aspects) est souvent très ralentie, voire complètement bloquée par les
exploitants, qui arguent, souvent à juste titre et parfois de façon abusive, un risque
élevé de régression de service. Un soutien fort et répété de la DSI est indispensable
pour avancer dans ce projet.
Gestion des identités et des droits : la gestion des droits applicatifs est du ressort des
métiers. Seuls les métiers peuvent décider qui a droit à quoi dans une application.
Pourtant, ces mêmes métiers résistent à s’impliquer dans les revues de droits, si bien
que la gestion des droits a souvent du mal à atteindre un niveau de maturité
satisfaisant. Quant aux projets d’IAM, ils sont longs, complexes et très coûteux à
mettre en place. Ils se concluent souvent par des échecs.
PCA/PRA : mettre en œuvre concrètement un plan de continuité d’activité est très
complexe. Cela mobilise des compétences techniques très variées et très sollicitées
d’ordinaire. Il faut par ailleurs impliquer les métiers dans cette démarche. Bref, le
RSSI a souvent du mal à convaincre toutes ces équipes de se consacrer pendant
plusieurs semaines à la préparation d’un test de continuité, et ce au détriment de toutes
les autres activités.
Gestion des antivirus : l’expérience montre qu’il est très difficile de faire en sorte
que la console d’administration de l’antivirus couvre l’ensemble des postes de travail
et des serveurs. Il y a toujours un pourcentage, souvent non négligeable, de postes non
gérés, que personne n’arrive à corriger. On peut même se poser la question suivante :
parvient-on au final à avoir un antivirus bien déployé et à jour sur tous les postes ?
Tiers : il est certes très facile de mettre en place un processus de gestion des tiers. En
revanche, obtenir de tous ces tiers une mise à jour satisfaisante des clauses
contractuelles en matière de sécurité est beaucoup plus ardu. De plus, il n’est pas
toujours aisé de s’assurer qu’ils observent les bonnes pratiques de sécurité, d’autant
plus que le rapport de force avec certains sous-traitants n’est pas toujours en faveur du
client. Ce dernier a donc souvent du mal à auditer son fournisseur.
Sécurité applicative : nombreux sont les progiciels ignorant complètement la
sécurité. Quant aux applications historiques développées en interne, elles sont souvent
très difficiles à mettre à niveau. Une proportion non négligeable du parc applicatif de
l’entreprise demeure vulnérable de façon endémique, malgré toute la bonne volonté
du RSSI.
Cette longue liste nous conduit directement à un premier constat : il est difficile de
terminer simultanément tous les projets de sécurisation, ce qui ralentit très concrètement
la sortie de la zone d’humiliation. Pire, nous venons de voir que certains de ces projets ne
se terminent jamais.
données, car les exploitants redoutent des régressions de service, si bien que le projet
n’avance que très lentement. Enfin, il reste les équipements d’infrastructure que l’on
oublie souvent : hyperviseurs de machines virtuelles, contrôleurs de baies de disques,
cœurs de réseau, répartiteurs de charge, etc. Comment avoir la certitude que l’on n’a
rien oublié ? Or, tant qu’un élément clé du SI dispose d’un mot de passe trivial, le SI
est en danger.
Serveurs : la sécurisation des serveurs (dont le changement de mots de passe n’est
qu’un des aspects) est souvent très ralentie, voire complètement bloquée par les
exploitants, qui arguent, souvent à juste titre et parfois de façon abusive, un risque
élevé de régression de service. Un soutien fort et répété de la DSI est indispensable
pour avancer dans ce projet.
Gestion des identités et des droits : la gestion des droits applicatifs est du ressort des
métiers. Seuls les métiers peuvent décider qui a droit à quoi dans une application.
Pourtant, ces mêmes métiers résistent à s’impliquer dans les revues de droits, si bien
que la gestion des droits a souvent du mal à atteindre un niveau de maturité
satisfaisant. Quant aux projets d’IAM, ils sont longs, complexes et très coûteux à
mettre en place. Ils se concluent souvent par des échecs.
PCA/PRA : mettre en œuvre concrètement un plan de continuité d’activité est très
complexe. Cela mobilise des compétences techniques très variées et très sollicitées
d’ordinaire. Il faut par ailleurs impliquer les métiers dans cette démarche. Bref, le
RSSI a souvent du mal à convaincre toutes ces équipes de se consacrer pendant
plusieurs semaines à la préparation d’un test de continuité, et ce au détriment de toutes
les autres activités.
Gestion des antivirus : l’expérience montre qu’il est très difficile de faire en sorte
que la console d’administration de l’antivirus couvre l’ensemble des postes de travail
et des serveurs. Il y a toujours un pourcentage, souvent non négligeable, de postes non
gérés, que personne n’arrive à corriger. On peut même se poser la question suivante :
parvient-on au final à avoir un antivirus bien déployé et à jour sur tous les postes ?
Tiers : il est certes très facile de mettre en place un processus de gestion des tiers. En
revanche, obtenir de tous ces tiers une mise à jour satisfaisante des clauses
contractuelles en matière de sécurité est beaucoup plus ardu. De plus, il n’est pas
toujours aisé de s’assurer qu’ils observent les bonnes pratiques de sécurité, d’autant
plus que le rapport de force avec certains sous-traitants n’est pas toujours en faveur du
client. Ce dernier a donc souvent du mal à auditer son fournisseur.
Sécurité applicative : nombreux sont les progiciels ignorant complètement la
sécurité. Quant aux applications historiques développées en interne, elles sont souvent
très difficiles à mettre à niveau. Une proportion non négligeable du parc applicatif de
l’entreprise demeure vulnérable de façon endémique, malgré toute la bonne volonté
du RSSI.
Cette longue liste nous conduit directement à un premier constat : il est difficile de
terminer simultanément tous les projets de sécurisation, ce qui ralentit très concrètement
la sortie de la zone d’humiliation. Pire, nous venons de voir que certains de ces projets ne
se terminent jamais.