lancer tête baissée dans la sécurisation des serveurs, en commençant par les plus
sensibles. Pourtant, procéder comme cela est la garantie d’un échec presque immédiat.
En effet, c’est sur ce parc de serveurs qu’il rencontrera les plus grandes réticences de la
part des équipes de production. Le RSSI doit donc jouer sur plusieurs leviers.
Dédramatiser : la première priorité sera de dédramatiser la sécurisation des serveurs.
Il faudra montrer que sécuriser un serveur ne génère que très rarement des régressions
de service.
Motiver : le RSSI a tout intérêt à motiver les équipes de production pour qu’elles
s’impliquent dans la sécurisation des serveurs.
S’adapter à la production : la sécurisation devra impérativement se fondre dans le
courant des tâches prioritaires réalisées par la production. Le RSSI doit donc proposer
une démarche progressive, adaptable aux contraintes des équipes de production.
Paradoxalement, la meilleure façon de dédramatiser la sécurisation des serveurs consiste
à attendre… Attendre que les mises à jour des postes de travail soient installées et
opérationnelles. Ceci montrera à la production de façon factuelle qu’appliquer les mises à
jour ne génère pas forcément de régression de service.
Ensuite, le RSSI demandera à la production d’identifier deux ou trois serveurs jugés peu
sensibles. C’est par ces serveurs que l’on commencera la sécurisation. Le but est que les
équipes chargées de la sécurisation « se fassent la main » sur ces systèmes, puis
procèdent à un retour d’expérience. Le constat sera fait qu’aucune régression de service
n’a été rencontrée.
Une fois ces machines témoins traitées, il reste à motiver les équipes de production pour
qu’elles s’impliquent dans le projet de sécurisation. Pour cela, le RSSI dispose de deux
leviers dont il ne doit pas se priver.
Premier levier : le RSSI commencera par sensibiliser toute l’équipe de production.
L’idéal est de recourir à des démonstrations de piratage sur un serveur, soit en les
réalisant lui-même, soit en les déléguant à des experts. Le but ici est de montrer
l’incroyable facilité de pirater un serveur non sécurisé et de faire comprendre que cela
n’arrive pas qu’aux autres. Cette démonstration mettra en évidence que le
désagrément pour les équipes à se faire pirater est bien supérieur à celui de sécuriser
les serveurs.
Second levier : en complément de la sensibilisation, le RSSI doit convaincre le DSI
d’intégrer la sécurisation du parc des serveurs dans les objectifs annuels du
responsable de la production. Ainsi, le responsable de la production aura un intérêt
personnel à faire avancer le projet. Il n’hésitera plus à s’impliquer et répercutera cet
objectif sur ses équipes.
Maintenant que l’on sait, d’après les faits, que la sécurisation des serveurs est peu risquée
et que les équipes de production sont motivées, on peut enfin commencer la vraie
sécurisation du parc. Cette sécurisation doit s’opérer en mode projet, c’est-à-dire qu’un
responsable sera désigné. Il disposera d’une liste précise des serveurs, avec leur nom,
adresse IP, version de système d’exploitation et fonction. Un ticket d’intervention sera
créé pour chaque machine à traiter (ou groupe de machines), pour un bon suivi de la
sécurisation du parc. Toutes les semaines, le RSSI, accompagné du responsable de la
sensibles. Pourtant, procéder comme cela est la garantie d’un échec presque immédiat.
En effet, c’est sur ce parc de serveurs qu’il rencontrera les plus grandes réticences de la
part des équipes de production. Le RSSI doit donc jouer sur plusieurs leviers.
Dédramatiser : la première priorité sera de dédramatiser la sécurisation des serveurs.
Il faudra montrer que sécuriser un serveur ne génère que très rarement des régressions
de service.
Motiver : le RSSI a tout intérêt à motiver les équipes de production pour qu’elles
s’impliquent dans la sécurisation des serveurs.
S’adapter à la production : la sécurisation devra impérativement se fondre dans le
courant des tâches prioritaires réalisées par la production. Le RSSI doit donc proposer
une démarche progressive, adaptable aux contraintes des équipes de production.
Paradoxalement, la meilleure façon de dédramatiser la sécurisation des serveurs consiste
à attendre… Attendre que les mises à jour des postes de travail soient installées et
opérationnelles. Ceci montrera à la production de façon factuelle qu’appliquer les mises à
jour ne génère pas forcément de régression de service.
Ensuite, le RSSI demandera à la production d’identifier deux ou trois serveurs jugés peu
sensibles. C’est par ces serveurs que l’on commencera la sécurisation. Le but est que les
équipes chargées de la sécurisation « se fassent la main » sur ces systèmes, puis
procèdent à un retour d’expérience. Le constat sera fait qu’aucune régression de service
n’a été rencontrée.
Une fois ces machines témoins traitées, il reste à motiver les équipes de production pour
qu’elles s’impliquent dans le projet de sécurisation. Pour cela, le RSSI dispose de deux
leviers dont il ne doit pas se priver.
Premier levier : le RSSI commencera par sensibiliser toute l’équipe de production.
L’idéal est de recourir à des démonstrations de piratage sur un serveur, soit en les
réalisant lui-même, soit en les déléguant à des experts. Le but ici est de montrer
l’incroyable facilité de pirater un serveur non sécurisé et de faire comprendre que cela
n’arrive pas qu’aux autres. Cette démonstration mettra en évidence que le
désagrément pour les équipes à se faire pirater est bien supérieur à celui de sécuriser
les serveurs.
Second levier : en complément de la sensibilisation, le RSSI doit convaincre le DSI
d’intégrer la sécurisation du parc des serveurs dans les objectifs annuels du
responsable de la production. Ainsi, le responsable de la production aura un intérêt
personnel à faire avancer le projet. Il n’hésitera plus à s’impliquer et répercutera cet
objectif sur ses équipes.
Maintenant que l’on sait, d’après les faits, que la sécurisation des serveurs est peu risquée
et que les équipes de production sont motivées, on peut enfin commencer la vraie
sécurisation du parc. Cette sécurisation doit s’opérer en mode projet, c’est-à-dire qu’un
responsable sera désigné. Il disposera d’une liste précise des serveurs, avec leur nom,
adresse IP, version de système d’exploitation et fonction. Un ticket d’intervention sera
créé pour chaque machine à traiter (ou groupe de machines), pour un bon suivi de la
sécurisation du parc. Toutes les semaines, le RSSI, accompagné du responsable de la