Gestion des incidents de sécurité dans un système
d’information avec RT (Request Tracker )

ANALYSE ET DEFINITION DES CONCEPTS DE BASE

 Dans ce deuxième chapitre, nous allons appliquer notre méthodologie de travail; il s’agira d’abord d’étudier l’existent, d’analyser les besoins, ensuite de définir les concepts de bases sur les informations de management des évènements de la sécurité et de la gestion d’incidents, pour enfin faire une étude comparative des différents outils de gestion d’incidences sur le marché. II.1 Evaluation des besoins 

Analyse de l’existant 

L’Agence De l’Informatique de l’Etat du Sénégal offre en direction des entités administratives, un service d’hébergement qui s’appuie principalement sur des serveurs web. Ce service, en termes de gestion des journaux d’évènements de sécurité repose sur une architecture centralisée. L’infrastructure de gestion des évènements de sécurité génère un volume important de journaux d’évènements aux formats syslog, evt et evtx. Ces évènements sont soit générés, soit identifiés ou bloqués par les IDS (intrusions Détection System) et les WAF (Web Application Firewall) installés sur les serveurs. L’IDS permet de repérer tous les activités anormales ou suspectes sur la cible analysée (un réseau ou un hôte). Il permet ainsi d’avoir une connaissance sur les tentatives réussies comme échouées des intrusions. Le WAF peut être un appareil, ou un plugin de serveur, ou un filtre qui applique un ensemble de règles pour une conversation HTTP. Généralement, ces règles couvrent les attaques courantes telles que le cross-site Scripting (XSS) et l’injection SQL. En personnalisant les règles de nombreuses attaques peuvent être identifiés et bloqués. Tous ces divers évènements seront centralisés et managés par OSSIM (Open Source Security Information Management). On a constaté aussi que la gestion des incidents provenant du SIEM est manuelle, il n’existe pas une base de données des incidents et une absence de base de résolution des incidents. 

 Identification de piste de solution

 Les problèmes précités soulèvent un grand nombre de besoins qui peuvent être pris en compte par une équipe de gestion des incidents de sécurités appelés CSIRT. Les CSIRTs sont capables de collecter, agréger, normaliser, corréler et traiter les évènements et incidents de sécurité d’un System d’information.

Présentation d’un SIEM

 Etant donné que l’étude d’un SIEM a été traitée par mon prédécesseur, après avoir fait une brève présentation d’un SIEM je vais passer directement à la présentation d’un CERT Les SIEM sont des outils de supervision de la sécurité, ils sont habilités à recevoir des journaux d’évènements et des flux d’information en provenance d’une grande variété d’actifs de support de service (Firewall, IPS, IDS, Antivirus, Active Directory, systèmes de contrôle d’accès, systèmes de gestion des identités, équipements de la VOIP, systèmes DLP, serveurs de messagerie…).. Ils combinent deux éléments principaux : Figure 3: Vue synoptique d’un SIEM Les SEM pour Security Events Management qui garantissent le traitement des événements, c’est-à-dire la supervision à temps réel, la collecte et la corrélation de données. Les SIM pour Security Information Management qui, eux, se focalisent sur l’analyse des informations; ils fournissent un moyen de rétention de données et de reporting d’événements. La supervision centralisée de la sécurité du système d’information par les outils SIEM se réalise en plusieurs étapes: la collecte, la normalisation, l’agrégation, la corrélation, le reporting, la réponse et le stockage.

Présentation d’un CERT/CSIRT 

Aujourd’hui on peut entendre parler de CSIRT (Computer Security Incident Response Team) ou de CERT (Computer Emergency Response Team). Derrière ces deux acronymes se cachent des équipes d’experts en sécurité informatique organisées pour réagir en cas d’incident informatique. Le terme CERT est le plus utilisé et le plus connu mais il s’agit d’une marque américaine qui appartient à l’université Carnegie Mellon. Les CSIRT peuvent demander l’autorisation d’utiliser le nom de « CERT ». Aujourd’hui, 79 CSIRT sont autorisés à utiliser la marque « CERT ». Figure 4: Logo attestant l’utilisation du nom CERT Généralement un CSIRT est une équipe de sécurité opérationnelle, composée d’experts de différents domaines (malwares, test d’intrusion, veille, lutte contre la cybercriminalité, forensics…). Elle est chargée de prévenir et de réagir en cas d’incidents de sécurité informatique. En amont, elle assure notamment une veille sécurité (les nouvelles attaques, les nouveaux logiciels malveillants, les dernières vulnérabilités) pour « connaître » l’état de la menace et évaluer les propres vulnérabilités de son organisation. En aval, elle analyse et traite les incidents de sécurité en aidant à leur résolution. C’est une équipe qui centralise et sert de relais que ce soit en interne et ou externe de l’entreprise car la communication est une de ses fonctions principales. 

 Les différents types de CSIRT

 Il existe plusieurs types de CSIRT. Il peut s’agir d’un CSIRT interne (d’entreprise ou d’une administration / université / Etat…) comme on trouve, par exemple, chez de grands groupes bancaires comme BNP Paribas et Société Générale. Le CSIRT a alors un rôle d’ « alerte » et de cyber pompier, prêt à intervenir pour aider et conseiller l’ensemble du groupe, ses filiales voire ses clients en cas d’incident de sécurité. On retrouve également des CSIRT « commerciaux ». Ce sont des équipes d’experts appartenant à des prestataires de services qui vont proposer des offres de veille, de réponse à incidents et de forensics (investigation numérique légale) à leurs clients. C’est donc un CSIRT externalisé et mutualisé. 

Avantages fonctionnels d’un CSIRT

 L’avantage d’un CSIRT/CERT est de centraliser la réponse à incident mais également de servir de relai vers l’intérieur de l’organisation (pour prévenir les menaces en informant et sensibilisant) et surtout vers l’extérieur à destinations des autres CSIRT et CERT et de la communauté pour la sécurité en général. Les CSIRT/CERT peuvent aider l’administration sénégalaise:  dans la gestion de sa cyber-sécurité,  dans l’appropriation des connaissances nécessaires en matière de gestion proactive et réactive des incidents de cyber-sécurité,  à la mise en place des politiques nécessaires pour sa cyber-sécurité,  à la mise en pratique de méthodes de travail adéquates à une culture de la cyber-sécurité au sein de l’administration.  regrouper les CSIRT de la sous-région, du continent et leur permettre de coopérer 

 L’Etat des CSIRT en Afrique et au Sénégal

 Il n’existe pas encore de CSIRT national au Sénégal alors que l’Agence de régulation de la Cote d’Ivoire a déjà mise en place un, appelé CI-CERT. La République de Maurice a mis en place l’un des meilleurs Computer Emergency response Team (CERT) d’Afrique. Un projet de mise en place de CERT a aussi commencé au Ghana où les législateurs se penchent sur une loi contre la cybercriminalité. Avec l’appui des Nations Unies qui ont développé un centre Africain de prévention de la cybercriminalité, alors tout l’enjeu pour l’Afrique sera la capacité des Etats à mutualiser leurs efforts et leurs infrastructures pour coopérer afin d’assurer la coordination entre les différents CERT nationaux et privés d’Afrique mais aussi internationaux. Mais, le Sénégal semble être sur la bonne voie. Car un projet de CERT piloté par l’ADIE et l’armée est en cours de réalisation. On notera que ce sont deux prestataires de services, ce qui démontre que le besoin des entreprises à recourir à ce type de service est de plus en plus fort. Ce faible nombre de CSIRT « officiels » ne signifie pas non plus que certaines entreprises privées ne disposent pas en interne d’équipe de réponse à incidents. Seulement, elles ont peutêtre fait le choix de ne pas créer des CSIRT publiques. C’est l’exemple des banques comme la SGBS. Mais il faut quand même avouer qu’encore beaucoup d’entreprises ne disposent pas de ce type de compétences en interne. Souvent par manque de moyens (il reste assez difficile de dénicher des profils expérimentés) ou de volonté. Certaines d’entre elles préfèrent faire appel à des CSIRT étrangers qui sont souvent « commerciaux » 

Présentation de l’outil 

Request Tracker (RT) C’est un système de suivi d’incidents extensible. Request Tracker (RT) est un système de billetterie qui permet à un groupe de personnes à gérer efficacement les tâches, les questions et demandes présentées par une communauté d’utilisateurs. Il dispose d’interfaces de ligne de commande (voir les paquets rt4-clients), email et web. .etc RT gère les tâches essentielles telles que l’identification, la hiérarchisation, l’affectation, la résolution et la notification requise par les applications critiques de l’entreprise y compris la gestion de projets, d’assistance, CRM (Customer Relationship Management=gestion de la relation client) et développement de logiciels. a °) Les objets de RT  La file : Au commencement est la file. Et particulièrement la file générale qui est même la première et indestructible file. Une file est un conteneur à tickets, un ticket représentant une demande et toutes les informations nécessaires ou relevées pendant son traitement. Une file peut avoir pour but de regrouper les demandes destinées à une équipe particulière (les administrateurs système par exemple), les demandes émanant d’un client particulier (son point d’entrée unique), ou servir de pseudo-liste de diffusion ou boîte aux lettres d’équipe, comme une file dont l’adresse est abonnée aux listes de sécurité. Les attributs d’une file sont ses deux adresses de messagerie, des priorités initiale et finale, ainsi que l’échéance normale de résolution d’un ticket.  Le ticket : Le ticket est la représentation d’une demande ou d’un incident qui devra être résolu, et dont il faut garder trace. Un ticket dans RT se voit attribuer un acteur et un seul (qui est Nobody au départ) ou propriétaire, qui a pour charge de mener à bien la résolution de cette demande. C’est cet acteur qui va pouvoir en modifier l’état ou statut (nouveau, ouvert, bloqué, résolu, rejeté, effacé). L’état nouveau est l’état par défaut d’un ticket venant d’être créé : personne ne l’a pris (le propriétaire change) ni n’a commencé à travailler dessus (passage à l’état ouvert). On peut passer un ticket à l’état bloqué pour signifier qu’il est en attente de quelque chose, l’effacer s’il avère que l’anti-spam n’a pas fait son travail, en cas d’activation des demandes par mail ou le rejeter si le demandeur n’a pas fait son travail en amont (RTFM). On peut enfin résoudre une demande (passage à l’état résolu) afin de le faire disparaître de la base des tickets actifs. Il a aussi un ou plusieurs demandeurs, des personnes en copie, un niveau de priorité et un ensemble de dates (création, butoir, résolution effective). Des observateurs peuvent être définis pour un ticket, ou plus généralement sur une file (toute une équipe) voire globalement. Ces observateurs peuvent être au même niveau que le demandeur, ou au même niveau que les acteurs : un demandeur ou une personne en Cc: ne verront que les correspondances, l’acteur ou ses pairs verront les correspondances et les commentaires sur le ticket. C’est là qu’interviennent les deux adresses de messagerie d’une file : il y a une adresse pour les correspondances (seule utilisable par les demandeurs), une autre pour les commentaires. Des champs temporels peuvent être définis comme le temps passé (rempli manuellement), le temps estimé de résolution, l’échéance prévue pour la résolution, le temps restant avant cette échéance, ainsi que des priorités, allant de 0 à 99. La sémantique associée à ces priorités devra être définie avant de commencer à utiliser RT, de façon à ce que tout le monde se mette d’accord sur la priorité « très urgent »… Ça évitera de voir des tickets de priorité 20 traîner car un acteur s’est mis 20 comme limite, alors que ses voisins de bureau qui le remplacent pendant ses vacances mettent la barre de l’urgence à 50… Dernière chose primordiale, l’historique du ticket, qu’il n’est normalement pas possible de modifier dans RT. Cet historique est constitué des messages échangés entre demandeurs et acteurs, des commentaires des acteurs (successifs), et des notifications des actions prises par RT, soit dans son fonctionnement normal, soit par le biais d’un scrip, comme les changements de priorité, d’acteurs, etc.  Des champs personnalisés On peut aussi associer à un ticket des champs personnalisés qui permettent d’ajouter des sémantiques personnalisées à ceux-ci. Ces champs personnalisés sont définis au niveau global, et associés aux tickets soit à ce même niveau global, soit file par file. Cela peut représenter des champs de formulaire avec des données qu’on aimerait obligatoires (on ne peut pas encore obliger un acteur à renseigner un champ, mais ça va venir dans les prochaines versions), le nom du client, le poste de facturation ou que sais-je encore. Je laisse votre imagination faire ses preuves sur le sujet :-). Créer des champs personnalisés Mais comme tout objet de RT, les champs personnalisés sont soumis à des contrôles d’accès. Il faut que les utilisateurs et/ou les groupes concernés disposent du droit « FixerChampsPersonnalisés ». Ensuite, la création de champs personnalisés se fait par le menu « Configuration » / « Champs Personnalisés » / « Nouveau champ personnalisé ». Il est possible ensuite de laisser fixer des valeurs à choisir ou au contraire de laisser le champ libre aux utilisateurs pour saisir des mots dans les champs personnalisés, mais l’exploitation n’en sera que plus difficile.