We normally think of data loss prevention (DLP) as something to limit employee errors, insider risks and poor data-management...
business processes, not external attacks. But in some of the recent, massive, financial data breaches (such as Heartland Payment Systems) it appears that DLP would have detected, if not stopped, the attacks.
While definitive information hasn't been released, sources are reporting that the perpetrators penetrated the networks (possibly using malicious software), installed sniffer software somewhere in the transaction pipeline, and exfiltrated the data over the network without encryption or any other obfuscation.
Exfiltrating stolen data over the network isn't anything new; if you think about it, the only alternative is to drive to the victim's location and physically retrieve it. In the 2005 CardSystems breach, the attackers used nothing more complex than FTP to retrieve their stolen data. Although malicious attackers have a myriad of options to export their ill-gotten gains, as recent events seem to indicate, they are just as likely to rely on the most basic of network channels.
This is exactly the kind of risk DLP is designed to mitigate, but it is only effective when configured properly and combined with additional security controls.
The first step is to ensure that your DLP has access to any outbound connections that might originate from your transaction processing network. If all your Internet traffic goes through established gateways this isn't a problem, but some organizations connect their transaction network through dedicated Internet pipes that won't be monitored by anything on the standard enterprise gateway. Since the transaction network also probably connects to your regular business network, it's important to put network monitors on both gateways.
Although all major network DLP solutions can sniff all possible network traffic, some users restrict their tools to only certain kinds of traffic, or only protocols running on standard ports. Attackers are very likely to use unusual combinations, so you shouldn't restrict your DLP tool and may need to add extra resources to keep adequate performance.
DLP tools only block traffic when combined with a network proxy (some use TCP resets, but that has limited usefulness). Thus it's crucial to properly manage your egress filtering so the DLP solution can block as much as possible, and the rest of your network security makes it extremely difficult for attackers to use unmonitored channels. To monitor SSL communications, you'll also need a gateway that proxies SSL connections.
Finally, some DLP tools also alert when they detect encrypted files. This won't catch all the malicious transmissions, but it will force the attackers to use non-standard encryption tools.
DLP clearly can't detect and prevent all data exfiltration by an intelligent attacker, but it does reduce the risk and there's no excuse for letting them get away with plain text and standard network channels.
About the author:
Rich Mogull has more than 17 years experience in information security, physical security, and risk management. Prior to founding independent information security consulting firm Securosis, Rich spent seven years at research firm Gartner Inc., most recently as a vice president, where he advised thousands of clients, authored dozens of reports and was consistently rated as one of Gartner's top international speakers. He is one of the world's premier authorities on data security technologies.