The Data Loss Prevention product at Netskope offers a wide variety of options to customize and deploy rules that can be used in Realtime, API protection, SMTP proxy and Endpoint policies. The granular level of detailing helps information security engineers to fine tune the rule as much as possible to avoid false positives and false negatives. The same approach applies for password protection too. Passwords act as the first line of defense against unauthorized access. Strong password protection is essential for safeguarding company data, maintaining compliance, and preventing unauthorized access. 

In the customer zero program at Netskope, our team has been extensively working on training the DLP rules, analyzing the false positive incidents, ensuring that the DLP rules cover different types of passwords (common, contextual, secure and so on) by actively collaborating with the relevant product teams. After some intensive training and testing, here’s the recommended DLP rule for password protection which has helped prevent the exposure of passwords to unintended audiences. 

This rule ensures the following types of passwords are detected by the DLP engine:

• Contextual passwords like mysql_root_password=abcd1234, password: lightsaber and so on.
• Common passwords like 123123, passwOrd, wizard1.
• Secure passwords which include a combination of alphabets, numbers and symbols. 

Sometimes, when this DLP rule is applied for SMTP proxy policies where passwords sent in emails can be detected and stopped, it can also trigger alerts for calendar invites that may contain passcodes for joining virtual meetings. With that in mind, we can modify this a little further to not detect such email forwards. 

For this use case, we can create a dictionary of words or sentences that are part of such calendar invites. 

This csv file can be uploaded as a dictionary (case insensitive) under DLP profile -> DLP rules -> Entities.

The dictionary entity can then be used in the DLP rule in the format listed below:

From here, this DLP rule can be used in different policies according to specific use cases. 

We would love to hear your feedback regarding this approach.