Procédure de gestion des incidents

La politique de gestion des incident a pour objectif d'assurer la détection et la remontée des événements, leur identification en tant qu'incident de sécurité, leur traitement par les équipes du Centre de Calcul et la communication associée en fonction de leur gravité et leur contribution à l'amélioration continue de l'analyse des risques et du SMSI.

• Le deux CSSI du CCUB sont en charge de la création des tickets d'incident et de la communication avec les usagers.
• Le responsable d'exécution du SMSI est en charge de la définition, de la coordination et du suivi des actions de gestion d'incident.
• Les exploitants sont en charge des interventions techniques en réponse ou en prévention d'incidents.
• Le COPIL SMSI est l'instance d'arbitrage concernant les actions à entreprendre.

En cas d'absence ou d'indisponibilité du responsable d'exécution du SMSI, tout CSSI du Centre de Calcul peut s'y substituer.

Un événement peut être détecté par :

• Le personnel du CCUB
• Les usagers
• Des moyens techniques (outils de supervision)
• Un intervenant extérieur

Les utilisateurs ont deux moyens pour alerter les chargés de sécurité de l'information de centre de calcul et le responsable d'exécution du SMSI :

• Via une adresse courriel fonctionnelle dédiée au traitement et au suivi des incidents de sécurité : incidents.hds@u-bourgogne.fr

• Via un ticket de demande de service conformément à la Procédure de demande de service

Ces deux canaux d'alerte constituent les demandes de service. A réception de la notification de l'évènement, le premier CSSI du Centre de Calcul disponible crée un ticket de demande de service , qu'il s'agisse ou non d'un incident de sécurité.

Les utilisateurs sont informés de ces moyens d'alerte et de remontée des incidents de sécurité par la Charte des utilisateurs et administrateurs du Centre de Calcul

Le CSSI ou l'exploitant évalue lors de la création du ticket ou de la prise en compte d'un ticket de demande de service s'il s'agit d'un incident.

Tous les événements portant sur la confidentialité des données sont considérés comme des incidents ainsi que les vulnérabilités pertinentes.

Les CSSI participent périodiquement (tous les trimestres) à des réunions d'informations autour de la SSI. Les supports de ces réunions sont consultables sur l'intranet de l'université de Bourgogne.

Les événements portant sur l'intégrité ou la disponibilité sont considérés comme des incidents uniquement s'ils sont imputables au CCUB. Par exemple, une indisponibilité résultant d'une erreur de manipulation d'un utilisateur ou d'une défaillance de son fournisseur d'accès ne sera pas classé comme incident de sécurité.

Dans le cas d'un incident, le ticket saisi doit contenir la description précise de l'incident :

• Date et heure de survenue
• Utilisateurs impactés
  • Au moins la personne ayant adressé le mail initial ou la demande service.
  • Éventuellement l'ensemble des utilisateurs de son organisation
  • Éventuellement l'ensemble des utilisateurs du centre de calcul
• Impact observé
• Type d'actifs affectés, présence d'actions d'urgence dans sa fiche
• Le niveau d'urgence

• Lorsque l'incident concerne une classe d'actif sensible pour laquelle des actions d'urgence sont définies, celles-ci doivent être exécutées immédiatement.

Le niveau d'urgence des incidents est basé sur la gêne occasionnée pour les utilisateurs :

• Basse - Le problème peut être contourné sans difficulté ou n'entraine aucun risque significatif (exemple - une opération échoue immédiatement et doit être répétée pour aboutir)
• Moyenne : Le problème est gênant pour effectuer les tâches requises ou présente un risque de sécurité potentiel (exemples: déconnexions intempestives, une sauvegarde n'est pas effectuée en temps utile)
• Haute : Le problème empêche d'effectuer certaines tâches ou présente un risque de sécurité avérée. Il touche une part significative des utilisateurs.
• Critique : Le problème interdit le fonctionnement ou présente un risque de sécurité certain (exemples : site inaccessible, accès à un port inapproprié ouvert sur Internet)

Le niveau de priorité d'un incident détermine son mode de traitement, ainsi que le délai au bout duquel le responsable d’exécution du SMSI escaladera vers l'ensemble des membres du COPIL SMSI :

Les délais indiqués sont en heures et jours ouvrés. : Réévaluer ces délai pour voir si il sont réalistes.

Les critères saisis lors de la création du ticket peuvent être réévalués collégialement par le COPIL SMSI. Un ticket saisi en tant qu'incident de sécurité peut également être requalifié en incident hors sécurité ou en demande de service, notamment s'il ne concerne pas des systèmes en production ou comportant des données sensibles.

Le responsable d’exécution du SMSI notifie immédiatement le COPIL SMSI à chaque création d'un ticket d'incident de priorité Haute (pour information) ou Critique (pour constitution de la cellule de crise).

Le CSSI du Centre de Calcul doit assigner le ticket à une personne qui sera responsable de son traitement. Cette assignation est notifiée par mail à l'ensemble des utilisateurs associés au ticket.

La personne à laquelle le ticket a été assigné, si elle estime n'être pas apte à y répondre, peut saisir un membre du COPIL SMSI pour réviser cette assignation.

Au ticket d'incident sont associés un journal public et un journal privé.

Les intervenants documentent leurs actions dans le journal privé. Ils y consignent les observations permettant de remonter aux causes et sur lesquelles ils ont basé leurs décisions de traitement pour analyse ultérieure lors de la revue de l'incident.

Lorsque c'est pertinent (exemple : malware, porte dérobée, rançongiciel, accès administrateur illicite), les équipements concernés sont déconnectés physiquement du réseau.

Le journal public est mis à jour par les CSSI du Centre de Calcul, le responsable exécution du SMSI ou le COPIL SMSI. Chaque mise à jour est transmise par mail à l'ensemble des utilisateurs associés au ticket. La fréquence minimale et l'origine de ces communications dépendent du niveau de priorité de l'incident.

Le journal privé sert à consigner des détails de traitement superflus pour l'utilisateur.

Contrairement aux incidents hors sécurité, le traitement des incidents de sécurité ne peut être suspendu en attente d'éléments complémentaires.

Si le traitement est une intervention technique de routine, il est appliqué directement par les exploitants. Dans le cas contraire, le responsable exécution du SMSI définit la marche à suivre avant d'éventuelles interventions techniques.

Le responsable exécution du SMSI (ou son suppléant) pilote les actions à effectuer pour résoudre les incidents ou rétablir le service. Il garantit une mise à jour du journal public au moins une fois par jour ouvré.

Didier : Prévoir comm par mail pour les problème d'infrastructure

La cellule de crise est constituée des membres disponibles du COPIL SMSI. Elle se réunit dès la notification d'un incident critique, physiquement ou en téléconférence.

La cellule de crise décide :

• De la communication détaillée vers les utilisateurs
• Des actions palliatives à mettre en œuvre

La communication détaillée contient au moins les informations suivantes :

• Date et heure de survenue de l'incident
• Nature de l'incident
• Impact
• Délai de rétablissement estimé.

La cellule de crise reste mobilisée jusqu'au rétablissement, et garantie une communication vers les utilisateurs au moins toutes les deux heures jusqu'à la mise en œuvre d'une solution palliative ou curative.

Si l'incident ne présente pas d'impact visible pour les usagers, il n'y a pas de communication obligatoire.

Il n'y a pas de fréquence de communication imposée, le CSSI du Centre de Calcul informe les utilisateurs au moins lors du rétablissement du service.

La communication de fin d'incident critique annonce la publication d'un rapport d'analyse sous un délai de deux jours ouvrés.

La résolution de l'incident signifie le retour à un fonctionnement normal, mais n'exclut pas des actions complémentaires.

Pour tous les incidents quelle que soit leur priorité, le ticket est complété lors de l'incident.

Dans le cas d'un incident de sécurité, le responsable exécution du SMSI

• Collecte les preuves
• Étudie les causes de l'incident
• Détermine si l'incident révèle une non-conformité dans la mise en œuvre des mesures ou une insuffisance dans l'analyse des risques, et si c'est le cas propose au COPIL SMSI la création des actions correspondantes.
• Produit un rapport interne d'incident sur la base des actions et observations consignées, complétées si nécessaire avec l'aide des intervenants et l'observation des traces techniques.

La fermeture d'un ticket d'incident doit être effectuée dans les 15 jours suivant sa résolution.

A chaque réunion trimestrielle du COPIL SMSI, les rapports internes de l'ensemble des incidents de sécurité du trimestre écoulé sont revus. On vérifie pour chacun d'entre eux :

• S'il n'est pas révélateur d'un problème plus général, des incidents antérieurs similaires ayant été traités de manière trop ponctuelle. Si tel est le cas, le COPIL SMSI programme des actions complémentaires ou un travail de fond au titre de l'amélioration continue.
• Lorsque c'est pertinent, le COPIL SMSI décide de faire remonter l'information au travers de la chaine fonctionnelle SSI.
• L'existence et l'avancement d'actions correctives
• La mise à jour de l'analyse des risques
• Le cas échéant mise à jour des mesures
• Le cas échéant mise à jour des procédures