Une forteresse sans sentinelles
À ce stade de son travail, le RSSI a considérablement sécurisé le SI. Les postes de travail
sont configurés dans les règles de l’art, les serveurs sont enfin patchés, les droits sur les
applications critiques sont corrects, l’architecture réseau est conçue conformément aux
usages et les liaisons distantes sont maîtrisées. En principe, le SI est donc dans une
situation nettement meilleure que lorsque le RSSI a pris ses fonctions.
Maintenant, une question que l’on peut légitimement se poser est la suivante : qu’est-ce
qui prouve au RSSI que le système est réellement sécurisé tel qu’on le lui annonce ?
Comment sait-il que les postes de travail sont bien configurés ? Comment s’est-il assuré
que les serveurs se sont vus réellement appliquer les correctifs de sécurité ? Comment
avoir la certitude que les 150 règles du pare-feu ne contiennent pas des failles permettant
à des flux illicites de pénétrer le réseau interne ?
Nous avons insisté tout le long de cet ouvrage sur la confiance et sur les bonnes relations
que le RSSI doit cultiver avec tout le personnel de l’entreprise, mais la confiance envers
les équipes (et notamment les équipes d’exploitation et de développement) ne peut pas
être l’unique indicateur de la bonne sécurisation du SI.
En fait, on en arrive à une situation paradoxale où le SI est potentiellement devenu une
forteresse, mais où son gardien (le RSSI) n’a aucun moyen fiable de vérifier si une porte
a été laissée grande ouverte ou si les fenêtres sont bien fermées. Un tel SI est une
forteresse sans sentinelles.
Certes, les différentes équipes chargées des processus de sécurité opérationnelle
fournissent en toute bonne foi des états générés par leurs outils, mais cela ne vaut pas un
regard indépendant.
Il est indispensable que le RSSI se munisse d’outils pour contrôler les divers aspects clés
de la sécurité. Ces outils doivent à la fois être indépendants des équipes chargées de la
sécurisation, et industriels afin de produire des diagnostics et des états facilement et à
grande échelle. La suite de ce chapitre détaille en quoi peuvent consister de tels outils.
À ce stade de son travail, le RSSI a considérablement sécurisé le SI. Les postes de travail
sont configurés dans les règles de l’art, les serveurs sont enfin patchés, les droits sur les
applications critiques sont corrects, l’architecture réseau est conçue conformément aux
usages et les liaisons distantes sont maîtrisées. En principe, le SI est donc dans une
situation nettement meilleure que lorsque le RSSI a pris ses fonctions.
Maintenant, une question que l’on peut légitimement se poser est la suivante : qu’est-ce
qui prouve au RSSI que le système est réellement sécurisé tel qu’on le lui annonce ?
Comment sait-il que les postes de travail sont bien configurés ? Comment s’est-il assuré
que les serveurs se sont vus réellement appliquer les correctifs de sécurité ? Comment
avoir la certitude que les 150 règles du pare-feu ne contiennent pas des failles permettant
à des flux illicites de pénétrer le réseau interne ?
Nous avons insisté tout le long de cet ouvrage sur la confiance et sur les bonnes relations
que le RSSI doit cultiver avec tout le personnel de l’entreprise, mais la confiance envers
les équipes (et notamment les équipes d’exploitation et de développement) ne peut pas
être l’unique indicateur de la bonne sécurisation du SI.
En fait, on en arrive à une situation paradoxale où le SI est potentiellement devenu une
forteresse, mais où son gardien (le RSSI) n’a aucun moyen fiable de vérifier si une porte
a été laissée grande ouverte ou si les fenêtres sont bien fermées. Un tel SI est une
forteresse sans sentinelles.
Certes, les différentes équipes chargées des processus de sécurité opérationnelle
fournissent en toute bonne foi des états générés par leurs outils, mais cela ne vaut pas un
regard indépendant.
Il est indispensable que le RSSI se munisse d’outils pour contrôler les divers aspects clés
de la sécurité. Ces outils doivent à la fois être indépendants des équipes chargées de la
sécurisation, et industriels afin de produire des diagnostics et des états facilement et à
grande échelle. La suite de ce chapitre détaille en quoi peuvent consister de tels outils.