I’ve been recently digging deeper into network DLP (part of a PCI initiative in an organization). I’ve long narrowed my eyes about the concept of the DLP space, but I feel a lot better about it lately. Let me briefly explain…keeping in mind I am discussing network DLP and not endpoint DLP.
My original thinking about DLP has always been how it has so many limitations. It is fun to make a list of all the ways you can circumnavigate the functions DLP provides. This always made me sigh in exasperation about DLP (data loss prevention!) as a security tool to prevent data loss. It’s not that I wanted DLP to be infallible, but I thought it was silly that even simple things could defeat it, like HTTPS/SSL, or a password-zipped file.
But now I believe DLP is not supposed to strictly be a security tool. DLP should better be labeled as a Sensitive Business Process Identifier. What DLP really does is identify and alert on business processes sending XYZ data over channels they’re supposed to be using, or they should not be using. Instead of stopping a malicious individual from exfiltrating information, DLP really wants to act like bumpers in the gutters of a bowling lane: make sure valid business processes aren’t using poor channels to move data, and somewhat log/assure when it is used properly. My old thinking involved malicious activity; my new thinking involves business-valid activity. That’s a big difference!
Does this satisfy PCI checks? Technically, I guess so. But does it offer much assurance that data is not exfiltrating a network? No. Does DLP make a security geek feel good? Not when considered alone. When considered as an advanced item in a mature security posture, then perhaps it is merely ok.
A very valuable side benefit of DLP’s approach is to drive identifying where sensitive data resides and transits. This is almost worth the cost of DLP to many companies that have no idea where this stuff sits or moves.