Quels sont les apports d’ITIL® pour la sécurité de l’information (et vice-versa) ?

Le référentiel ITIL® peut-il contribuer à la sécurité du SI et inversement ? Cet article tente de donner quelques éclairages, pour guider le RSSI (ou le consultant SSI).

Bien qu’en charge de la sécurisation du système d’information, le RSSI n’est pas obligatoirement imprégné des processus organisationnels qui sous-tendent l’activité de sa DSI, du fait d’un parcours professionnel qui peut être différent de ses collègues DSI.
Est-ce problématique ? Comment en effet parvenir à améliorer la sécurité du SI ? Faut-il au préalable améliorer la maturité des pratiques DSI ? Ces deux objectifs sont-ils totalement disjoints ? Ou sont-ils mutuellement inclusifs, à la manière du Yin et du Yang ? Eclairages.

Apports d’ITIL® pour la sécurité de l’information

La sécurité de l’information peut bénéficier d’une organisation de DSI en phase avec les meilleures pratiques ITIL® (« Information Technology Infrastructure Library ») et les 25 processus de ce référentiel*.

Ainsi, un processus de gestion des vulnérabilités – et un processus de gestion des incidents de sécurité, tous deux non référencés dans ITIL® v3- pourront se greffer efficacement sur Incident Management & Problem Management pour la partie traitement, sur Event Management pour la partie détection, et sur Change Management pour l’implémentation des correctifs.

Mais quelle description le RSSI ou consultant SSI devra-t-il donner de ces processus de gestion des vulnérabilités / incidents de sécurité ? Là encore, ITIL® rappelle les meilleures pratiques liées à la définition des processus. Ceux-ci doivent obligatoirement comprendre :

1. une liste d’activités,
2. des rôles et responsabilités,
3. des KPI pour en surveiller le fonctionnement.

Apports de la sécurité de l’information pour ITIL®

À l’inverse, quels sont les apports de la sécurité de l’information pour ITIL® ? Certes, produire une valeur via les services IT implique d’apporter une utilité aux clients (domaine métier). Mais également de fournir un certain nombre de garanties de fourniture de ce service. C’est là où interviennent les 4 processus Availability Management, Continuity Management, Capacity Management, Information Security Management (les 3 premiers étant plutôt focalisés sur la disponibilité de l’information, le dernier couvrant l’ensemble des critères de sécurité D/I/C/P).

D’autres irruptions de la sécurité sont possibles (et encouragées) :

• dans la phase « stratégie des services », le Service Management For IT Services devrait s’appuyer sur une Politique de Sécurité des Systèmes d’Information et une cartographie/analyse des risques SI,
• dans la phase « conception des services », le Service Level Management devrait comporter un volet pour les cas d’incidents de sécurité ; quant au Supplier Management, il devrait comporter la rédaction de Plans d’Assurance Sécurité,
• dans la phase Transition des Services, la CMDB (Configuration Management Database) produite par le SACM (Service Asset & Configuration Mgmt.) identifiera les besoins de sécurité des CI (Configuration Items) ; le Release & Deployment Management sera consolidé par des mesures de sécurité (techniques ou organisationnelles) assurant l’intégrité des paquets logiciels déployés,
• dans la phase « opération des services », l’Access Management s’appuiera sans surprise sur un certain nombre de services de sécurité.

Conclusion sur le référentiel ITIL®

Est-il prérequis qu’une organisation adopte les meilleures pratiques ITIL® pour pouvoir améliorer son niveau de sécurité de l’information ? La réponse est non …même si cela aiderait grandement ! Cette organisation (qu’elle soit ITILienne ou pas) devrait en tout cas considérer l’introduction de la sécurité de l’information aux niveaux stratégique, tactique et opérationnel, le tout en démarrant bien entendu par la démarche fondatrice qu’est l’analyse de risque sécurité.

* Ces derniers sont systématiquement indiqués en anglais italique,
 pour les distinguer les processus non ITIL®