Pouvoirs du RSSI, une approche Itil de la question

Une part d’entre eux considère que le RSSI est une sorte de gardien du temple avec droit de vie et de mort sur certaines décisions à caractère technique : politique de filtrage URL, connexion d’un PC sur le LAN, etc. On trouve dans cette catégorie les moins avancés, ceux qui confondent encore système informatique et système d’information, et qui s’imaginent avoir un PRA parce qu’ils disposent d’une seconde salle informatique. 

Pour l’autre part, les plus avancés, le RSSI est en réalité un officier Sécurité informatique, qui n’a comme valeur ajoutée que sa capacité à faire en sorte que les MOA se posent les bonnes questions sur leur niveau de risque. Cette approche, pour moderne qu’elle soit, présente malgré tout un inconvénient : si tout processus métier est fournisseur de ses clients (internes ou non) et client de ses fournisseurs (internes ou non), rien n’empêche a priori un fournisseur interne (par exemple la DSI) de dégrader son niveau de service sans en alerter ses clients (les processus métiers).

Itil propose une approche aussi simple que redoutable de la notion de processus, qui est caractérisé par trois paramètres : son SLA (Service Level Agreement, ou catalogue de services), son OLA (Operational Level Agreement, organisation interne au processus pour rendre le SLA), et ses UC (Underpinning Contracts, ou contrats passés avec ses propres fournisseurs). Les UC d’un processus sont donc les SLA de ses fournisseurs, et inversement. Partant de cette modélisation, il n’existe que deux situations où le RSSI a un pouvoir de blocage.

D’abord, la modification d’un SLA par un fournisseur ne doit pas être réalisée sans la validation du client. Après tout, rien n’empêche de vendre des 2CV, quand bien même on proposait des Rolls par le passé, si le client n’a besoin que de 2CV : encore faut-il qu’il en soit prévenu et qu’il valide ce nouveau niveau de service. Pour exemple, je n’ai rien contre le fait que les sauvegardes ne soient plus dédoublées, dès lors que les MOA ont acté explicitement l’augmentation mathématique du risque de perte de données (la question de savoir quelle MOA unique interroger sur ce sujet transversal est une autre paire de manches).

Ensuite, toute évolution de l’OLA et du SLA d’un processus ne doit être réalisée qu’après avoir validé que les UC sur lesquels s’appuie ce processus prennent bien en compte les nouvelles contraintes du client. C’est un grand classique dans les DSI : un « machin » anodin tombe en panne (par exemple le DECT d’un agent), et l’on se rend compte que tout le processus de gestion des greffons était basé sur un appel à ce DECT avec des renvois en cascade, ce qu’à aucun moment la DSI n’a validé. Sans compter que les systèmes de renvoi ne sont en aucun cas fiables en termes de disponibilité.

Autrement dit, personne ne vous interdit de courir en chaussettes et les yeux bandés sur un filin tendu entre deux immeubles du moment que vous êtes conscient de ce que vous faites : le pire risque n’est pas celui que l’on prend, mais celui que l’on prend ou que l’on fait prendre aux autres sans le savoir.