Gestion des services ITIL
L’ITIL a mauvaise réputation dans les milieux de la sécurité, généralement parce que certains l’ont mis en œuvre comme une simple formalité administrative plutôt que comme un moyen de bien gérer l’informatique. Je ne l’aborde pas de cette manière. Lorsque j’intègre les pratiques ITIL dans un environnement, je m’intéresse aux éléments qui réduisent réellement les risques : un processus de gestion des changements qui détecte une règle de pare-feu mal configurée avant sa mise en production, un processus de gestion des incidents qui achemine un événement de sécurité vers la bonne personne en quelques minutes plutôt qu’en plusieurs heures, et une base de données de gestion des configurations qui vous indique, en toute transparence, ce qui est en cours d’exécution sur votre réseau.
Pourquoi cela est-il important pour la sécurité ?
La plupart des violations de sécurité que j’ai analysées a posteriori s’expliquent par une lacune dans les processus, et non par l’absence d’un outil. Une modification non autorisée est déployée un vendredi après-midi. Un actif dont personne n’assurait le suivi fonctionne toujours sous un système d’exploitation en fin de vie. Un ticket d’assistance concernant une « connexion lente » s’avère être le premier signe d’une attaque par « credential stuffing », mais personne ne fait le lien car la gestion des incidents et celle des services fonctionnent en silos distincts. Une mise en œuvre efficace de l’ITIL comble ces lacunes en vous offrant une méthode rigoureuse pour gérer les changements, les incidents, les problèmes et les actifs comme un système unique et interconnecté.
Mon approche
Je commence par examiner ce que vous faites déjà, et non ce qu’un manuel vous dit de faire. La plupart des organisations ont mis en place une forme ou une autre de contrôle des changements et de gestion des incidents ; la question est de savoir si ces processus sont cohérents, si la sécurité est prise en compte dans les décisions stratégiques, et si les registres que vous conservez vous seraient réellement utiles en cas d’incident réel ou d’audit. À partir de là, je vous aide à renforcer les processus les plus importants — généralement la gestion des changements, la gestion des incidents et la gestion des configurations/actifs — et à établir des liens solides entre les opérations informatiques et l’équipe de sécurité, afin qu’une interruption de service et un incident de sécurité soient traités comme le même type de problème lorsque cela s’avère nécessaire.
Je ne tiens pas à vous remettre un manuel de procédures de 40 pages qui finira sur une étagère. Ce qui m’importe, c’est de savoir si votre comité consultatif sur le changement empêche réellement les changements risqués, si votre CMDB reflète bien la réalité, et si votre équipe est capable de répondre à la question « qu’est-ce qui a changé juste avant que cela ne tombe en panne ? » en quelques minutes plutôt qu’en plusieurs jours. Voilà le niveau d’exigence.
À qui s'adresse ce document ?
Cet ouvrage s'adresse aux organisations qui dépassent le stade des opérations informatiques ponctuelles, aux entreprises qui ont besoin de processus alignés sur l’ITIL pour répondre aux exigences de leurs clients ou de conformité, ainsi qu’aux équipes de sécurité qui en ont assez d’être les dernières informées lorsqu’un changement intervient en production.
Si votre processus de changement et votre programme de sécurité ne communiquent pas entre eux, cela mérite qu’on en discute. N’hésitez pas à me contacter et dites-moi où se situent les points de friction.