Dépannage DLP

Ce playbook décrit les étapes pour résoudre les problèmes lorsque DLP ne fonctionne pas comme prévu sur votre compte.

Présentation

Les complications avec les politiques de prévention des pertes de données (DLP) peuvent entraîner des résultats inattendus, ce qui entraîne des risques de sécurité potentiels. Cela peut être dû à une configuration qui ne s'aligne pas avec les exigences, ou à un type de données ou profil personnalisé défini de manière inexacte

Évaluation initiale avec les événements

Le filtrage des événements de prévention des pertes de données (DLP) à l'aide d'Événements peut être réalisé en définissant le préréglage "Sécurité des applications" :

Les événements associés à des règles de contrôle de données comprendront des champs informatifs tels que les profils DLP déclenchés, les types de données correspondants, les attributs de fichier et plus encore.

Cela vous permettra de comprendre ce qui est actuellement déclenché et de vous poser la question : 'Les résultats sont-ils conformes à ce que j'attendais en fonction de ma configuration ?'

Dépannage du problème

Le processus de dépannage est conçu pour être séquentiel, chaque étape dépendant de la précédente. Si une exigence précédente n'est pas remplie, les étapes suivantes ne seront pas déclenchées.

Remarque :

Note : Une exigence pour toutes les étapes ci-dessous est de s'assurer que vous avez une règle FW (même créée temporairement à des fins de dépannage) avec suivi des événements activé qui correspondra au trafic censé être inspecté par la DLP.

Une autre configuration orientée dépannage sera une règle DLP de secours capturant à la fois le téléchargement/téléversement à des fins de monitoring sans correspondance de contenu ou spécification de type de fichier.

Il est également recommandé de tester avec un fichier non textuel, tel qu'un document .docx ou .pdf, pour garantir qu'il n'y a pas de problèmes de détection de type de fichier liés aux fichiers textuels (plus de détails ci-dessous).

(1) Inspection TLS activée (pour le trafic sur TLS)

• Vérifiez dans l'événement du pare-feu : vérifiez le champ booléen inspection TLS dans l'événement FW généré et assurez-vous qu'il est défini sur 1. Si la valeur est définie sur 0,, assurez-vous de respecter les directives dans les articles suivants pour configurer et tester l'inspection TLS sur votre compte:
  - Configuring TLS Inspection Policy for the Account
  - Testing TLS Inspection in the Cato Cloud 

• Les systèmes d'exploitation spécifiques (Android, Linux, systèmes d'exploitation inconnus) ne sont pas inspectés par TLS.

• Certaines applications client natives ne sont pas inspectées TLS (en raison de préoccupations liées à l'épingle de certificat). Les règles de contournement par défaut TLS peuvent être identifiées dans le CMA.

• Assurez-vous que votre politique de pare-feu Internet contient deux règles avec une priorité élevée (près du sommet de la base de règles) pour bloquer QUIC et GQUIC, car l'inspection TLS ne peut pas fonctionner sur ce type de trafic :
  

  Pour vérifier si une certaine requête utilise ou non le protocole QUIC, générez un fichier HAR et inspectez la colonne "Protocole" de la requête POST/GET concernée. Si une demande utilise QUIC, elle sera répertoriée comme "h3", "http/2+quic/46" ou similaire:
  

(2) Vérifiez l'application de destination identifiée par Cato

• Vérifiez dans l'événement Firewall: Consultez le champ d'événement “Application” et recherchez l'application identifiée.

• Si votre application n'est pas correctement identifiée, assurez-vous que ce qui suit est vrai:

  • Vous accédez à la destination de l'application en utilisant son nom d'hôte au lieu d'utiliser directement l'adresse IP.

    • Cette étape garantit que CATO voit la requête DNS associée, nous permettant de dériver le nom d'hôte de la destination, ce qui est crucial pour la détection des applications.

  • Assurez-vous que le trafic destiné au serveur DNS que vous utilisez pour résoudre les noms d'hôte de l'application de destination est visible pour CATO (par exemple, atteint l'interface LAN du Socket)

• Vous pouvez définir soit une application spécifique pour les politiques CASB/DLP, soit sélectionner "Toute application" (tout le trafic applicatif HTTP/S).

  • La liste complète de ce que CATO définit comme "Applications Cloud" et "Applications" peut être trouvée sous "Ressources -> Catalogue d'applications" filtré par le type.
    

  • Vous pouvez ouvrir un ticket RFE (Request For Enhancement) auprès du Support de CATO si vous avez une application spécifique que vous aimeriez ajouter comme Application dans le Cloud.

(3) Vérification des exigences de taille de fichier

• Vérifiez dans l'événement DLP (sous-type "Sécurité des applications") : Cherchez le champ d'événement Verdict sur la menace et vérifiez si la valeur est définie sur Contourner par taille - voir cette valeur indiquera que le contenu n'a pas été analysé en raison de la taille du fichier ne correspondant pas à la plage de taille minimum/maximum requise.

• La taille maximale des fichiers pour DLP en ligne est de 50 Mo (500 Mo pour l'API de Protection des Données)

  • En général, vous pouvez identifier le comportement gzip en arrière-plan en suivant les étapes ci-dessous :

    • Ouvrir les outils de développement du navigateur, onglet "réseau"

    • En téléchargeant un fichier, repérez la requête qui représente le téléchargement (dans la suite Google, elle est probablement repérable en filtrant le domaine :*.googleusercontent.com, cadre bleu dans l'image ci-dessous)

    • Cherchez l'en-tête Content-Encoding dans la Réponse (cadre rouge dans l'image ci-dessous). Si c'est gzip, vous pouvez dire qu'il y a une compression sous le capot.
      

• Pour Profils OCR DLP La Taille du Fichier prise en charge est comprise entre 10KB et 50 MB

(4) Le type de fichier est identifié + pris en charge pour DLP

• Vérifiez dans l'événement DLP (sous-type "Sécurité des applications") : Cherchez le champ Type de fichier indiquant quelle classe de fichier a été détectée par Cato

• Si la valeur est Types de Fichiers Inconnus, cela signifie que CATO n'a pas pu identifier le fichier et qu'il est exempté du scan de contenu.

• Vérifiez que le type de fichier est pris en charge pour DLP : les fichiers audio, vidéo et binaires ne sont pas pris en charge.

• Une prudence particulière doit être exercée lors de la correspondance du fichier JAR à l'aide du type de contenu, car un fichier .JAR peut être soit une archive Zip, soit un fichier d'archive Java (JAR). Consultez La règle de contrôle des données ne fonctionne pas sur le fichier JAR lors de la correspondance par code source pour plus de détails.

• Pour Profils OCR DLP, les types de fichiers pris en charge incluent : PNG, JPEG, TIFF, BMP, PNM, WEBP, JPEG

Limitations de la détection des fichiers textuels

La détection des fichiers textuels, tels que CSV & TXT, fait face à des défis en raison de l'absence d'indicateurs spécifiques. Notre détection repose sur trois éléments principaux:

• Magiclib: L'en-tête d'un fichier unique à son type. Par exemple, les fichiers PDF commencent par un en-tête distinctif (%PDF-1.5, %µµµµ, etc.), servant d'indicateur fort du type de fichier.

• En-têtes HTTP: L'en-tête "Content-Type" dans les téléversements de fichiers peut indiquer le type de fichier, comme application/vnd.ms-excel pour les fichiers Excel lors d'un téléversement.

• Extension de nom de fichier: Utilisée lorsque d'autres indicateurs sont absents ou non concluants, en supposant que le nom de fichier est correctement extrait.

Les limitations surviennent avec les fichiers textuels parce qu'ils:

• Ils manquent d'un en-tête magique unique pour distinguer les types (CSV, TXT, script Python).

• Les requêtes HTTP pour les téléversements (par exemple, via curl) peuvent ne pas avoir suffisamment de métadonnées sur le type de fichier (par exemple, l'en-tête "Content-Type").

• Le nom de fichier pourrait ne pas être présent dans la requête HTTP.

  • Si le nom de fichier est absent des événements, veuillez contact Support

Ces facteurs peuvent rendre difficile de différencier entre un simple corps de texte dans une requête POST/PUT et un véritable téléversement de fichier textuel, ce qui peut entraîner le fait que DLP manque ces fichiers.

Pour d'autres limitations connues pour DLP, consultez Creating the Data Control Policy. 

(5) Le profil DLP correspond au contenu scanné

• Cette étape aide à déterminer si le problème provient de l'alignement du type de données avec le contenu du fichier

•  Outil de Validation DLP: La validation des types de données avec un fichier de test est une étape essentielle et utile dans le processus de dépannage. Il fournit un moyen pratique de valider les règles DLP avec des données du monde réel, servant de méthode efficace pour identifier et rectifier les problèmes.

  • Un exemple de validation réussie d'un Type de Donnée par mot-clé sur un fichier .csv :
    

  • Validation des Expressions Régulières : Lors de l'utilisation d'un Type de Donnée personnalisé avec regex, la boîte de test regex devient un atout inestimable. Elle vous permet de tester vos motifs regex et valider leur précision. Il est toujours conseillé de tester vos motifs ici d'abord pour éviter des résultats indésirables dans le système DLP.
    

  • L'option "Export Text Extracted" peut être utile pour examiner les données textuelles analysées du fichier telles qu'elles ont été scannées par le moteur DLP :
    

  • Par exemple, vérifier que les ID des étiquettes de sensibilité attachées à un document sont détectées peut se faire en examinant le fichier .txt généré par l'option "Export Text Extracted". Ci-dessous, le résultat textuel de l'analyse d'un fichier .docx contenant une étiquette MIP : mip-example.png