Vous êtes dans : Accueil > Tribunes libres >

ITIL v3 et le catalogue des services en sécurité SI – partie 1

Cédric Cartau, LUNDI 18 JANVIER 2016

La norme ITIL, dans sa version 3, réserve une place spécifique à la sécurité du SI. On retrouve le découpage classique en roue de Déming (PDCA) et les items habituels de planification, implémentation, audit, etc.

Intéressons-nous plus particulièrement au volet « disponibilité » de l'offre de service SI. Ce n'est bien entendu pas le seul aspect (il y a tout le DICP), mais la partie disponibilité est la plus simple à formaliser sous l'aspect d'un catalogue de service (SLA).

La première étape est de définir la liste des composants du SI qui sont officiellement identifiés comme critiques : ce qui est inclus dans la liste bénéficie d'un traitement particulier, ce qui n'y est pas est en mode best effort en termes de délais de remise en service. Cela sert notamment à officialiser ce qui est d'astreinte ou pas : les informaticiens d'astreinte disposent d'un document sur lequel se baser (qui n'a pas été écrit par eux, du reste) et qui les autorise à refuser de traiter un appel concernant un composant absent de la liste. 

La deuxième étape est de positionner un niveau de criticité pour chacun des éléments de la liste. Dans l'idéal, on définit trois niveaux de criticité standard (par exemple GOLD, SILVER et BRONZE) comportant chacun un engagement en termes de délai de remise en service. Par exemple 4h pour les composants en GOLD, 12h pour le SILVER et 48h pour le BRONZE. Il est possible d'affiner le modèle en distinguant les délais de remise en service pour les arrêts en heures ouvrables ou non ouvrables, de définir un quatrième niveau de service, etc.

La troisième étape est de positionner des responsables identifiés, à la fois côté DSI et côté MOA, pour chacun des composants listés. Quand l'un des éléments tombe en panne, qui prévenir en effet côté MOA ? Qui prend en charge côté DSI, à la fois sur le plan technique (système) et fonctionnel (AMOA) ?

La quatrième étape est de définir, pour chaque élément de la liste, au moins deux périodes temporelles pour les arrêts programmés de maintenance : une période pour les arrêts courts (moins de 30mn) qui doit obligatoirement se positionner en heures et jours ouvrables, une période pour les arrêts longs (plus de 30mn), qui doit se positionner hors heures ouvrables. On pourra également renseigner des conditions de déclenchement (par exemple avertir la MOA 1 semaine à l'avance avec un rappel à J-1). Cette formalisation permet de ne pas se reposer indéfiniment la question des arrêts, et de renégocier à chaque fois.

Avec cela, on est parés : bien entendu, à chaque nouvel ajout de composant, à chaque incident il convient de se poser la question de savoir si les éléments renseignés sont juste ou s'il faut les remettre à jour.

#sécurité#planification#sécurité du si#dsi


Les plus lus