Fuite de données dans un environnement bancaire

Fuite de données dans un environnement bancaire

Implémentation de nouvelles règles et optimisation

Dans les organisations, il existe des règles de sécurité standards même au sens DLP qui sont globales indépendamment du secteur d’activité. Mais en général, les règles de sécurité sont faites sur mesure et selon le fonctionnement de chaque organisation.Une des difficultés auxquelles les équipes de sécurité sont confrontées est le traitement d’énormes quantités d’anomalies de sécurité, dans lesquelles il existe plusieurs faux positifs. Dans les cas du Groupe, les ressources humaines ne sont pas assez nombreux pour gérer la quantité d’anomalies générées par le DLP. Ce qui augmente considérablement le risque de ne pas être en mesure de traiter les anomalies pertinentes, qui pourraient être de réels incidents de fuite de données avec des impacts sur l’entreprise comme on l’a décrit dans le chapitre 3 de ce document.
Après analyse des anomalies DLP, nous avons pu détecter plusieurs faux positifs réguliers. L’action suivante était de regrouper les anomalies par leurs éléments en commun (par exemple la source et la destination des événements) et définir une règle d’exception basée sur ces éléments en commun.Comme cas concret, nous avons par exemple identifié qu’une unité métier de gestionnaires de portefeuilles échangeait régulièrement via e-mail avec des partenaires gérants indépendants. Ces échanges contenaient des CID. Du point de vue sécurité, cela représente une anomalie et potentiellement un incident. Tandis que du point de vue métier, c’est un comportement normal. Nous avons donc mené un travail avec l’entité en question, afin de déterminer tous les partenaires avec qui leurs échanges contiennent des CID. Ce travail nous a permis de définir une règle d’exception pour cette unité en prenant en compte toutes les informations collectées. Ce
Contrôles de sécurité contre la fuite et vol de données processus a porté ses fruits et a été validé par le comité de sécurité pour son application avec d’autres unités métier identifiés. Ce processus permet de :
● Ne pas impacter les activités du métier
● Réduire le nombre de faux positifs
● Avoir une meilleure visibilité des anomalies
● Se concentrer sur les cas importants

Tests des règles nouvellement implémentées

Dans ce sous chapitre, nous allons prendre comme exemple l’optimisation décrite dans le souschapitre précédent, c’est-à-dire mettre en place une règle qui analyse les CID, et une exception selon les informations métiers. Pour ce faire, nous allons utiliser des données fictives pour des raisons de confidentialités.Pour cet exemple, les paramètres à prendre en compte sont les suivantes :
● Auditer les envois de 0 à 9 numéros de compte sur tous les canaux DLP
● Bloquer les envois de plus de 9 numéros de compte (considérons que l’envoie de plus de 9 numéros de compte est un envoi massif de CID) sur tous les canaux DLP
● Si l’adresse e-mail de destination est une adresse de la HEG Genève ou n’importe quelle HES-SO, et la source est un collaborateur du département sécurité, alors c’est un comportement normal du métier ; l’envoi de plus de 9 numéros de compte est autorisé et n’est pas audité Avec ces trois informations, nous allons mettre en place les éléments nécessaires à la création de la règle DLP et ensuite la créer, en suivant ces étapes :
● Créer une « Business Unit » nommée « Test_Security » et y ajouter les collaborateurs du département sécurité
● Créer un référentiel de données de type dictionnaire nommé « Test_HES_Domains » et y ajouter le nom de domaine de la HEG Genève « hesge.ch »
● Créer la police et la règle DLP qui audite ou bloque le trafic selon les recommandations. Nous allons les nommer « T_HEG » (dont T signifie test)
● Créer la règle d’exception nommée « T_E_HEG » (dont E signifie exception) selon les recommandations Supposons que la « Business Unit », le dictionnaire et la condition de la règle (voir la figure 8) sont déjà créés, et passons à la création de la règle DLP. Les figures suivantes montrent le plan d’action à mettre en place pour la règle DLP et la règle d’exception configurée.

Contribution à la gestion des incidents

De nouveaux types d’incidents de sécurité émergent fréquemment. De ce fait, le Groupe doit être préparé à faire face aux événements de sécurité connus ou inattendues. Pour assurer cette préparation qui permettra de réduire le nombre d’incidents de sécurité, des éléments de préventions, détections et réponses basés sur les résultats d’évaluation des risques doivent être adressés. Il est quand même à noter que pas tous les incidents de sécurité peuvent être évités.
Le Groupe poursuit le projet nommé ISIR (Information Security Incident Response) qui a pour objectif de décrire et mettre en place un cadre pour répondre aux incidents de sécurité. Actuellement à la phase de documentation, ISIR définit :
● Les caractéristiques des incidents de sécurité
● Les six phases de réponses aux incidents
● Les cas d’utilisations et manuel de réponse7 aux incidents de sécurité
● Les différents rôles et responsabilités

Revue du processus de la gestion des incidents DLP

En se basant sur les référentiels du SANS et NIST, un top 10 des incidents de sécurité a été défini et pour chaque type d’incident, un manuel de réponse sera établi. Le top 10 identifié de types d’incidents est le suivant :
● Ingénierie sociale ○ Pratique de manipulation incitant la victime à fournir des informations
● Actif compromis ○ Tels que des équipements réseaux et mobiles de l’entreprise, qui sont exploités par une personne malicieuse avec comme résultat une perte de la confidentialité, l’intégrité ou la disponibilité
● Fuite de données ○ Mouvement non-autorisé des données généralement vers l’extérieur de l’entreprise. Par exemple des CID et documents stratégiques sensibles
● Déni de service ○ Attaque ayant pour objectif de rendre un service indisponible
● Destruction/perte d’actif
● Accès non-autorisé ○ Aussi référé comme une intrusion
● Attaque zero-day
● Informations d’identification compromises
● Attaque par défiguration
● Violation de politique de sécurité Le Groupe a basé son plan de réponse aux incidents de sécurité sur le modèle à six phases du SANS, qui sont :
● Préparation ○ Cette phase inclut les tâches qui doivent être exécutées afin de se prémunir ou éviter l’occurrence d’un incident de sécurité, ou de limiter son impact
● Identification ○ C’est la phase de reconnaissance d’un incident. Les incidents sont soit remontés par les utilisateurs finaux soit détectés par le SIEM et d’autres outils de détection
● Endiguement ○ Dans cette phase on met en place des moyens afin de limiter les dommages causés par un incident
● Éradication ○ Le but de cette phase est de mettre en marche le plan de remédiation suite à l’endiguement, et de restaurer les systèmes affectés
● Récupération ○ Dans cette phase on remet les systèmes affectés en production, une fois restaurés
● Leçons apprises ○ L’une des phases les plus importantes ; son but est de finaliser la documentation de l’incident, fermer l’incident et déterminer les plans d’actions pour améliorer le processus de gestion d’incidents

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela chatpfe.com propose le téléchargement des modèles complet de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

Contrôles de sécurité contre la fuite et le vol de données dans un environnement bancaire
Déclaration
Remerciements
Résumé
Liste des tableaux
Liste des figures
1. Introduction
2. Présentation du Groupe
3. Fuite de données dans un environnement bancaire
3.1 Définition de la fuite de données
3.2 Causes de la fuite de données
3.2.1 Convictions des lanceurs d’alertes
3.2.2 Raisons financières
3.2.3 Espionnage industriel
3.2.4 Sabotage
3.3 Canaux de fuite de données
3.3.1 Papier
3.3.2 Électronique
3.3.3 Voix
3.4 Vecteurs de fuite de données
3.4.1 L’être humain
3.4.2 Infrastructure et application informatique
3.5 Impact de la fuite de données pour l’entreprise
3.6 Moyens de protection
3.6.1 Sécurité du système d’information
3.6.2 Principe du « need to know »
3.6.3 Exercice de gestion de crise 3.6.4 Formation
4. Objectifs
5. Déroulement
5.1 Analyse de l’existant
5.1.1 Analyse de l’état des lieux actuel du DLP
5.1.2 Analyse de l’outil de traitement des logs
5.2 Gestion des risques internes
5.2.1 Configuration de l’outil DLP du Groupe
5.2.2 Participation à l’amélioration de règles de détection des fuites de données
5.2.3 Contribution à la gestion des incidents
5.3 Gestion des risques externes
5.3.1 Étude des éventuels contrôles DLP dans un environnement cloud
5.3.2 Initiation au SIEM
5.4 Revalidation des accès
5.4.1 Configuration de l’outil de supervision pour la revalidation des accès
5.4.2 Campagne de revue des accès aux applications critiques
5.4.3 Campagne de revue des accès aux répertoires sensibles
6. Analyse des objectifs
6.1 Objectifs du Groupe
6.2 Objectifs personnels
8. Conclusion
Bibliographie
Annexe 1 : Moyens de contrôles des risques liés au cloud
Annexe 2 : Échelles d’évaluation des risques du Groupe
Annexe 3 : RACI ISIR
Annexe 4 : Abréviations