C'est vendredi après-midi et une panne de stockage a frappé plusieurs systèmes. Outre la restauration du service, une deuxième horloge est maintenant en marche : si cela constitue un incident majeur, il doit être signalé dans un délai court. Quelqu'un pose la question : « Quels services ont été touchés, combien d'utilisateurs, et à quel point sont-ils critiques ? » La réponse est reconstituée à partir de la supervision, d'un tableur de services et de la mémoire de collègues expérimentés. Les mêmes questions reviennent lors d'une inspection – seulement plus tard, et avec une demande de preuves.
Ce que les réglementations exigent
NIS2 et DORA diffèrent dans leur portée et leurs autorités de contrôle, mais d'un point de vue des opérations informatiques, les mêmes exigences reviennent :
- connaître l'impact d'une panne sur les services et leur criticité,
- signaler les incidents majeurs dans des délais définis et avec des preuves suffisantes,
- gérer les changements et les vulnérabilités et être en mesure de montrer qui a approuvé quoi,
- garder une vue d'ensemble des services et des fournisseurs ICT dont les opérations dépendent,
- retracer la responsabilité – qui est propriétaire du service et qui a changé quoi, quand.
Aucune de ces exigences n'est nouvelle. Ce qui est nouveau, c'est la pression pour que les réponses soient rapides, complètes et prouvables.
Ce que Stilla couvre aujourd'hui
La fondation des réponses réglementaires est les données que Stilla conserve pour les opérations quotidiennes :
- Une cartographie des dépendances du service métier à l'infrastructure et au calcul de l'impact qui prend en compte la redondance – clusters, réplication de bases de données, stockage miroir.
- Un propriétaire pour chaque service, rôles définis et une matrice RACI que Stilla vérifie par rapport aux autorisations.
- Un historique de vérification immuable pendant cinq ans ; pour la configuration, l'état avant et après un changement est stocké.
- Des changements gérés approuvés par le propriétaire du service affecté, fenêtres de maintenance et gel des changements.
- Des contrats de service et des SLA de fournisseur, y compris l'escalade des incidents au fournisseur selon le contrat.
- Des vulnérabilités par service avec des délais par gravité, distinguant les failles activement exploitées.
Lorsqu'un incident se produit, Stilla montre les services affectés à partir de la cartographie des dépendances, et non à partir d'une estimation. Le propriétaire du service peut être retrouvé, et l'historique des changements montre ce qui a changé ces derniers jours.
Ce qui est en préparation
En plus de ces données, nous construisons des sorties réglementaires qui ne font pas encore partie du produit :
- Classification des incidents majeurs selon les critères NIS2 et DORA, dérivée de l'impact dans la CMDB,
- Un rapport pré-rempli avec chronologie et impact,
- Un registre des services et des fournisseurs ICT sous DORA.
Le principe restera le même que dans le reste du produit : Stilla prépare les preuves, une personne décide et soumet toujours. Nous confirmerons la synchronisation de la sortie avec les clients pilotes.
Où commencer
Une réponse réglementaire n'est aussi bonne que les données qui la sous-tendent. C'est pourquoi nous recommandons de commencer là où cela rapporte même sans réglementation : avec les services clés, leurs propriétaires et la cartographie des dépendances. Celui qui a cela en ordre a la plupart du travail fait – et un vendredi après-midi, des réponses à partir de données, et non de la mémoire.
Stilla ne remplace pas l'évaluation juridique. Examinez les obligations spécifiques de votre organisation avec votre équipe de conformité.
Stilla Standard
Pour les organisations qui souhaitent une CMDB fiable et des processus ITSM gérés.