You will still lose data so is DLP worthwhile?

Today I was reading an article titled: Data Leak Prevention Bypass which got me thinking about all the data loss vectors which I had considered when making the business case for DLP in the past. The author has an interesting project of a device that uses the keyboard USB interface to bypass protection of removable media control. The wrong message to take from this is that DLP is not worthwhile because it can be bypassed

Defining the problem

Data loss is now an accepted risk in the security industry. Data needs to move for business to run and provide business value. You have to provide someone with access to your most sensitive data - either directly e.g. an application user or admin or indirectly e.g. a database administrator.  Once users have access they will store it on their local machine, manipulate it in spreadsheets stored on share drives, email it etc. These new locations may not have the same access controls, it is easy to make an error to write too much data to a CD or USB which gets lost or copy the wrong person on an email. Also who likes to re-invent the wheel? When leaving a company it is tempting to take reference material and anything that will give you an edge - e.g. Microsoft employee recently

Data loss vectors

Building a tool to use the USB keyboard port represents a technical and motivated attacker. Of course if and when you can simply buy such a USB device then it becomes accessible to the masses.

But we were able to brainstorm a lot more easier ways to get data out of an organization even with a DLP tool in place and well configured (covering Internet, Email and Endpoints) and removable media locked down:
  • Print - nice and easy. Not as convenient as having the data electronically and you won't be able get a large database without killing a lot of trees but still a viable channel. Endpoint DLP configured to monitor data that is printed could detect this but this is typically not a priority to protect compared to email and internet
  • TLS sites - e.g upload to Dropbox or webmail over TLS. Unless the web proxy is terminating the TLS and the DLP sensor is behind this proxy this traffic will not be detected. Organizations can take the approach to block these types of sites but as with all blacklisting it is hard to get them all and some could be required for business purposes
  • Encrypted email and files - similar to TLS data could be encrypted prior to being emailed out or uploaded to the Internet. This could be via the enterprise email encryption software like PGP or simply setting a password on an Office file or Winzip password. If your network DLP sensor can decrypt traffic (e.g. by sending it to PGP for decryption) this can also work, but most likely you will miss it, endpoint DLP can detect this prior to the file being decrypted. 
  • Local hard drives - if users have a physical desktop and can copy data to a their local drive, taking this out overnight is not difficult. Can be mitigated by endpoint DLP stopping copying of sensitive data to local, blocking local drive access or use of virtual desktops only, but these measures will not be in place for most organizations
  • Floppy disk, Firewire, Blackberry sync - often holes in the removable media control policy which has focused on USB and CD/DVD. Floppy drives are rarely present these days but where they exist you can still get a spreadsheet with a client list or credit cards out on them. Firewire is almost forgotten but removable media devices connecting on Firewire can be as easy as USB. Finally most removable media control policies allow Blackberry and other mobile devices write access for sync purposes. Apps that allow you to copy data to and from PC and mobile can be used. This is the same as using the USB keyboard path, using an allowed path for an unauthorized purpose. Endpoint DLP can detect this if configured correctly
  • Mobile devices - in controlling removable media, mobile devices can often be missed. If policy allows an SD card to be used in a Blackberry or other forms of data backup and storage, data can be transferred to the mobile via sync or email and then transferred out. If mobile devices also do not have encryption of their internal storage, a more technical attack could be to remove this storage, connect it to an alternate device - similar to laptops before they had full disk encryption. Encrypting mobile storage is becoming similarly important now.
  • Images and cameras - print screen is a powerful function when combined with OCR these days. Most DLP will not currently detect sensitive data in images, although tools may evolve to contain functionality as available in forensics and internet content monitoring software. Almost everyone also has a phone with a camera - there is almost nothing you can do about that other than restricting users from having these device in highly sensitive zones (not practical for most places).
  • Authorized users - Some people will still have to be allowed to write to removable media, this could all be for legitimate business use such as transferring data to a vendor, writing an ISO file, marketing data provided on CD/USB. Once this access is granted it is the same problem as providing access to the information in the first place - it is hard to differentiate legitimate use from malicious use or loss due to error. Granting access on a temporary basis for a specific purpose can mitigate this but adds overhead and time. Reviewing the logs of data actually written by authorized users can be effective for small amounts of data. DLP tools that can calculate the risk score even for authorized or white listed users and flag this for review especially where this differs from a baseline is the most effective.
  • Coverage and tool error - It is very difficult to get a 100% coverage with DLP tools - covering all Internet and email egress points and ensuring all endpoints have the required agent. If the agent has minimal tamper-proofing a user with admin rights could simply stop the process, it could fail due to an error, helpdesk could remove it or disable it to solve a user error. Having monitoring and metrics of coverage and uptime of DLP tools just like AV is the key here.
  • Retrieval of company equipment - if the company is not diligent about retrieving USB devices, mobiles, laptops - this can be an easy way for data to leak. 

So is DLP worthwhile?

There are many ways that DLP can be bypassed and even with a fully deployed DLP solution data can still be lost or stolen. I don't think this makes DLP solutions useless though. Configuring DLP, especially endpoint DLP to consider these types of threats mean that they can be mitigated. It is also recognizing that your DLP solution is not going to be effective from day 1 and making sure expectations are set this way. In addition appreciating which threats DLP will be most effective against - primarily users making an error and users taking information when they leave the company.

Humans are prone to choose the path of least resistance - so covering corporate email, webmail and USB devices could be the 20% effort that provides you the 80% reduction in risk. Running tools in log mode to measure how much data is leaving via these means before and after policies are applied is also a good idea so you can demonstrate effectiveness with real numbers. Another option is to leave one of these methods like email or USB open (i.e. no preventative measures) but logged and risk scored by DLP. This means that people are less likely to choose a more convoluted means which you may not be monitoring and with timely monitoring and response you can still stop data loss.

There has to be an acceptance that you will never stop a truly skilled and motivated attacker from getting some information out of the organization. DLP will be least effective against threats such as a highly technical attacker sent in on a mission for corporate espionage. What you can do is make it as hard as possible for them, make them break down multiple layers of defence with monitoring to increase the chance that at each point they will be detected.

Photo credit: minor9th Flikr

No comments:

Post a Comment


Written by