Non, le DLP, ce n’est pas une société de livraison.
Qu'est ce que le Data Loss Prevention ?
Le « Data loss prevention», ou, dans la langue de Molière, la prévention de la fuite de données, c’est un ensemble de politiques/pratiques qui servent à empêcher que des données sensibles atterrissent là où elles ne devraient pas (comme un Boeing 737 max).
Si votre dirigeant vous demande : Pourquoi du DLP ?
=> Vous pouvez répondre : Parce que vous ne souhaitez pas que des informations confidentielles soient perdues, volées ou exposées au mauvais public par erreur.
Si votre dirigeant vous demande : de quelles données on parle ?
=> Vous pouvez répondre :
• Des données personnelles : noms, prénom, numéro de téléphone, adresses
• Des données personnelles sensible (quelle horreur! Imaginez un peu qu’on découvre que vous êtes platiste) : religion, orientations politiques
• Des secrets d’entreprise : contrats, ordre de production, données stratégiques
• Données de santé : votre dernière coloscopie
• Données juridiques : Casier judiciaire, informations liées à une sanction disciplinaire
Ces données sont d’usage considérées comme sensibles car leur fuite peut occasionner un impact juridique, financier, social, opérationnel, sur les biens et personnes ou réputationnel.
Là votre décideur va certainement vous demander : Ok et comment ça fonctionne concrètement ?
Pour protéger des données sensibles, il faut les identifier et identifier sur quels types de support elles se trouvent et qu’il devrait y avoir accès.
On classifie les données :
Très communément, on définit une échelle de classification à 4 ou 5 niveaux, par exemple
- Public
- Interne
- Confidentiel
- Très confidentiel
- Critique
On détermine la politique de traitement/stockage de la donnée selon sa classification :
Une politique se construit à l’aide de questions bien amenées, du type :
- Qu’est ce qui peut être envoyé par mail ?
- Qu’est ce qui en dois en aucun cas sortir de l’entreprise ?
- Qu’est qui doit être chiffré (au repos et/ou en transit) ?
Le petit moment concret :
- Des credential (login/mot de passe) administrateurs ne doivent en aucun cas transiter en clair via email ou chat direct.
- Un accès à un compte d’administration sur un système spécifique = un incident de sécurité majeur
On remonte ses manches et on déploie des outils DLP sur les environnements cibles :
Les données énoncées précédemment se situent essentiellement sur les supports suivants:
- Boites mails professionnelles
- Postes de travails
- SharePoint/ Drive/ Partage réseau
- Applications en SaaS
Vous trouverez nombre d’outils à déployer sur des environnements spécifiques (ex : Microsoft 365, Google Works pace), mais je ne fais pas de pub gratuitement ici.
En terme de couverture DLP, de manière très, très synthétique, une architecture DLP comprend :
- Les endpoints (solution DLP sur les Poste utilisateurs et postes administrateurs)
- Les boites mails (solution DLP couvrant également les Drives)
- Les applications cloud (CASB= Cloud Access Security Broker)
- Les requêtes vers l’extérieur (Firewall, proxy)
D’usage, lorsqu’on déploie en première instance une solution DLP, on débute par les environnements cloud et boites mails qui représentent l’écrasante majorité des fuites.
On crée les règles à implémenter dans les outils :
Comment on construit une règle ? Un peu comme un développeur débutant en python, à l’aide du SI … ALORS.
SI une donnée sensible est détectée, ALORS on agit
Le petit moment concret :
---------------------------------------------------------------------------------------------------------------------------------------
SI un email sortant contenant le mot-clé « licenciement »,
ALORS on bloque l’envoi et on informe l’expéditeur de manière pédagogique que cette donnée est sensible et doit être transmise via un autre canal sécurisé tel qu’un SharePoint.
=> On verra plus loin les paramètres possibles d’ajouter à une règle, je ne vais pas vous traumatiser dès que le début
---------------------------------------------------------------------------------------------------------------------------------------
SI un mot de passe administrateur est détecté dans un chat,
ALORS on bloque l’envoi et on informe l’utilisateur sur les raisons du blocage
---------------------------------------------------------------------------------------------------------------------------------------
SI un trafic HTTPS sortant contient des numéros de carte bancaire ou des IBAN vers un domaine externe,
ALORS bloquer la requête et alerter l’équipe sécurité.
---------------------------------------------------------------------------------------------------------------------------------------
Traitement du caractère légitime de l’accès.
C’est primordial d’empêcher la fuite de l’information mais il faut quand même que chacun puisse continuer de travailler ! Et pour cela certains doivent malgrè tout pouvoir transmettre et accéder à de l'information sensible
La gestion des identités et des accès est une discipline à part, que nous traiterons à part dans un autre article. Mais la cybersécurité n'ayant sens dans un cadre multidisciplinaire, nous allons devoir l'aborder ici.
Le principe fondamental en sécurité de celui du moindre privilège. Chacun n’accède qu’aux données nécessaires à son travail et pas plus.
La classification de la donnée nous donne un premier indicateur :
- Interne : Tout les employés peuvent y accéder
- Au-delà de Confidentiel : Seule l’équipe concernée peut y accéder et selon des modalités plus au moins stricte selon le niveau « confidentiel » et « critique ».
Le DLP vérifie que le destinataire est légitime et bloque le partage si s’il sort du périmètre et guide l’expéditeur vers le bon canal de transmission avec des règles de contexte liées à la durée d’accès, la localisation autorisée.
Le petit moment concret :
Un contrat client est envoyé par mail par un membre de l’équipe achat.
Le document est classé confidentiel car il contient par défaut des données juridiques, commerciales voire même des clauses plus sensibles qu’on n’oserait citer ici.
De fait, les règles qui vont régir le partage de ce type de document vont nécessiter une interdiction de partage publique, un partage externe limité dans le temps, chiffré et nominatif.
Conditions (SI)
- Un email sortant ou un import sur un partage cloud contient des mots-clés juridiques tels que : contrat, accord, conditions particulières, clause… ainsi que des données client (nom société, SIREN, signature)
- Le destinataire du mail est externe à l’entreprise
- Le document est classifié comme « Confidentiel »
Actions (ALORS)
- Bloquer l’envoi ou le partage si le dentinaire n’est pas :
- le client concerné
- un avocat référencé
- un partenaire autorisé à travailler, consulter le document
- Si le destinataire est légitime, on applique comme règle d’accès/partage :
- chiffrer automatiquement l’email ou le lien
- limiter l’accès à lecture seule
- définir une expiration (30 jours)
- chiffrer automatiquement l’email ou le lien
Rappel des bonnes pratiques et sensibilisation
En cas de blocage, on peut informer l’expéditeur de cette manière :
" Ce document est classé Confidentiel. Le partage externe est restreint. Merci d’utiliser le canal sécurisé ou de demander une autorisation."
C’est cordial et pédagogique !
Alertes & journalisation :
On enregistre l’événement DLP et on notifie l’équipe sécurité en cas de blocage
Les traces à stocker:
- utilisateur
- destinataire
- type de donnée
- action effectuée
La conclusion GRC :
- La cyber sécurité doit s’inscrire dans une démarche pédagogique, de gouvernance et d’amélioration continue ;
- La politique doit être revue régulièrement, tout comme les règles DLP et les exceptions ;
- Les incidents doivent être suivis et faire l’objet d’un apprentissage ;
- Les utilisateurs doivent être formés et informés de manière pédagogique, autrement ils contourneront les règles à la moindre occasion ;
- Faire de la veille sur les mises à jour des législations et référentiels (RGPD, NIS2, IA ACT, ISO27001, HDS...) ;
