Security Manager's Journal: DLP tool is suddenly blind to email

Computerworld - We had been making good progress in demonstrating the value of our still limited deployment of data leak prevention (DLP) technology until a setback a couple of weeks ago. Ironically, the setback was due to an expansion in the use of encryption, something that I would normally embrace wholeheartedly.

Some background: We rolled out DLP earlier this year, but with resource constraints; I've been seeking more backing for this technology by proving its worth in protecting the company's intellectual property. Given a tight budget, we decided it would be most effective to deploy DLP in a limited but highly targeted way. For example, we aren't alerted about every document containing the words confidential or restricted but instead rely on a recent audit that identified specific documents containing key sensitive data. This short list of highly sensitive data includes product road maps, source code, price books, business development plans and confidential financial data.

Meeting with representatives of each functional unit, we learned that some of these documents are stored in Microsoft SharePoint libraries and others on Unix Network File Shares or Microsoft CIFS File Shares. For example, the vice president of sales told us that price books are stored within a departmental share on a Windows file server and then sent out via email to a distribution list. With that information, we were able to configure our DLP software to automatically index that file share once per day, with the index matching so tight that even a small portion of the price book that was pasted into another document or email message could be identified.

Where Did It Go?

As a demonstration for management, we copied part of the price book, which is an Excel spreadsheet, and pasted it into an email message that was then sent to a webmail account. This triggered an alert notifying us that the email contained data from the price book. Score one for DLP. But a couple of weeks ago, this demonstration started to fail, because we were unable to see any of our Microsoft Exchange email traffic.

All the other network traffic was still visible; what happened to the Exchange traffic? The Exchange administrators told us that they had recently upgraded to Exchange 2010, which uses what is called opportunistic TLS to automatically encrypt all traffic between the Exchange server and our spam-filtering mail gateway, in the cloud. In addition, we are slowly migrating our on-premises Microsoft Exchange servers to Microsoft O365, a hosted Exchange environment that also encrypts traffic.

The problem is that our DLP monitors network traffic via a SPAN port and can't see encrypted traffic. I now have to deploy proxies to decrypt the SSL packets, pass the traffic to the DLP for inspection and then re-encrypt the traffic to its destination.

When I discussed this issue with my firewall engineer, he mentioned that our Palo Alto Network (PAN) firewalls could decrypt SSL traffic. That sounded like an easy and inexpensive way to inspect our traffic, but unfortunately, the PANs aren't ICAP-compatible. ICAP, which stands for Internet Content Adaptation Protocol, is the mechanism by which unencrypted SSL traffic is passed to our DLP for inspection. That means that I'm going to have to wait until 2013 to buy another tool, unless I can find a low-cost alternative.

One option we've been thinking about is Squid, which is an open-source proxy. But being open source, Squid doesn't come with any support, so it's not a long-term solution. The one thing that's certain is that we can't continue operating blind.

This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at mathias_thurman@yahoo.com.

Join in the discussions about security! computerworld.com/blogs/security

Read more about Security in Computerworld's Security Topic Center.