Let’s take the example of a credit card number: simply monitoring traffic for credit card numbers may trigger alerts anytime someone in the organization uses a credit card for any reason. So, an employee making an online purchase during a break may be blocked from making the purchase and the security administrator will receive an alert. In this case, the alert would be a “false positive,” so called because the system accurately detected an attempt to send credit card data, but the activity posed no risk to the organization. With EDM, only the specific credit card numbers that a company stores in its databases—such as those belonging to its customers or partners—would trigger alerts. That employee making a purchase would not trigger an alert and neither would the accounting department paying bills.

To clarify, most false positives are real positives, meaning the detection engine did its job and identified content that matches a policy. However, the content does not pose a risk to the business in the context it is being used. False positives have actual consequences. They don’t cause any direct harm, but they jam up the system. While the administrator weeds out hundreds of false positives every week, perhaps more, there is less time to investigate the legitimate alerts.

False positives have actual consequences. They don’t cause any direct harm, but they jam up the system. While the administrator weeds out hundreds of false positives every week, perhaps more, there is less time to investigate the legitimate alerts.

EDM “fingerprints” sensitive data from structured sources, such as databases or spreadsheets, then watches for attempts to move the fingerprinted data and to stop it from being shared or transferred inappropriately.

It starts with plain text from a database or Excel spreadsheet that contains the sensitive records. This data in these records is obfuscated—usually by hashing—for privacy reasons. With hashing, algorithms are applied to the data, turning it into shorter data strings (hashes), and those hashes are stored within the DLP solution. The same algorithms are then applied to all outbound traffic. So, when traffic that is hashed matches the hashes stored in the DLP solution, the transfer will be blocked or an alert will be triggered.

Why cloud-delivered EDM is ideal

Exact Data Match is a storage- and compute-intensive operation, requiring a highly scalable underlying platform that can accommodates its processing demands. Because Zscaler Cloud DLP with EDM is built on a global, multitenant cloud architecture, it detects and blocks attempts to send protected data no matter where the user connects or what applications are being used. There’s no impact on performance, and the centralized Zscaler admin portal provides real-time visibility into incidents.

Most DLP system do not have the ability to inspect encrypted traffic, leaving them blind to the majority of enterprise traffic. But Zscaler Cloud DLP is part of the integrated Zscaler Cloud Security Platform, which inspects all traffic, including all encrypted traffic.

With Zscaler EDM, you can fingerprint and match billions of cells of your unique sensitive data. Those fingerprints will be stored in the Zscaler cloud to give you the ability to stop data loss globally and at scale. Zscaler also helps you maximize your data protection even as you maintain compliance with industry mandates, such as HIPAA, as well as data privacy regulations like GDPR. Leveraging an extensive feature set, including EDM, machine learning, file type control, and granular policy that follows the user, Cloud DLP simplifies compliance with regional regulations.

A data loss prevention system with Exact Data Match, like Zscaler Cloud DLP, will help you increase your organization’s security posture, reduce the frustration of end users due to unnecessarily blocked transactions, and spend more of your time investigating and remediating actual incidents of data loss instead of digging through the haystack of false positives.