Freins à la sécurité des services
Dans l’absolu, la sécurisation des services ne devrait plus poser de problème depuis
longtemps, car tous les grands éditeurs de systèmes d’exploitation et de bases de données
proposent maintenant des modes d’installation sécurisée ainsi que des dispositifs de
mises à jour de sécurité. De plus, ces mêmes éditeurs, mais aussi des organismes publics,
mettent gratuitement à la disposition des administrateurs des guides de sécurisation très
précis et de très bonne qualité. Le RSSI n’a que l’embarras du choix à l’heure de choisir
un guide. Enfin, si la sécurisation des serveurs s’opérait jusqu’à récemment de façon
artisanale, serveur par serveur, des outils très performants ont permis d’industrialiser ce
processus sur tout un parc.
Pourtant, malgré tous ces points positifs, à l’heure de sécuriser les serveurs, le RSSI doit
affronter une très forte résistance tant de la part de la production que de la part des
équipes projet. En effet, prises par des délais toujours de plus en plus tendus, les équipes
projet voient d’un mauvais œil les contraintes liées à la sécurité. Elles redoutent que la
sécurisation des systèmes limite les fonctionnalités, rendant plus difficile le
développement, le test puis l’intégration des solutions qu’elles sont chargées de
construire. Quant à la production, elle redoute par-dessus tout que la sécurisation entraîne
une régression de service. Cette appréhension est bien légitime et ne manque pas de
fondement. Notons toutefois que ce risque de régression de service est trop souvent
invoqué pour ne rien faire…
Face à ces résistances, le RSSI doit jouer à la fois de fermeté, pour faire avancer la
sécurité, et de flexibilité, pour gagner la confiance des équipes. Pour cela, il doit mettre
en avant des précautions pour rassurer les uns et les autres. Il montrera qu’il n’est pas un
intégriste de la sécurité et proposera des modes opératoires réduisant au maximum les
risques de régression, le tout de façon très simple, pour ne pas compliquer la tâche des
exploitants.
Dans l’absolu, la sécurisation des services ne devrait plus poser de problème depuis
longtemps, car tous les grands éditeurs de systèmes d’exploitation et de bases de données
proposent maintenant des modes d’installation sécurisée ainsi que des dispositifs de
mises à jour de sécurité. De plus, ces mêmes éditeurs, mais aussi des organismes publics,
mettent gratuitement à la disposition des administrateurs des guides de sécurisation très
précis et de très bonne qualité. Le RSSI n’a que l’embarras du choix à l’heure de choisir
un guide. Enfin, si la sécurisation des serveurs s’opérait jusqu’à récemment de façon
artisanale, serveur par serveur, des outils très performants ont permis d’industrialiser ce
processus sur tout un parc.
Pourtant, malgré tous ces points positifs, à l’heure de sécuriser les serveurs, le RSSI doit
affronter une très forte résistance tant de la part de la production que de la part des
équipes projet. En effet, prises par des délais toujours de plus en plus tendus, les équipes
projet voient d’un mauvais œil les contraintes liées à la sécurité. Elles redoutent que la
sécurisation des systèmes limite les fonctionnalités, rendant plus difficile le
développement, le test puis l’intégration des solutions qu’elles sont chargées de
construire. Quant à la production, elle redoute par-dessus tout que la sécurisation entraîne
une régression de service. Cette appréhension est bien légitime et ne manque pas de
fondement. Notons toutefois que ce risque de régression de service est trop souvent
invoqué pour ne rien faire…
Face à ces résistances, le RSSI doit jouer à la fois de fermeté, pour faire avancer la
sécurité, et de flexibilité, pour gagner la confiance des équipes. Pour cela, il doit mettre
en avant des précautions pour rassurer les uns et les autres. Il montrera qu’il n’est pas un
intégriste de la sécurité et proposera des modes opératoires réduisant au maximum les
risques de régression, le tout de façon très simple, pour ne pas compliquer la tâche des
exploitants.