Wednesday, November 21, 2007

Technological Means to Prevent Data Leakage

Before we dive into “Geeky Stuff”, let me tell you what this article is not about. This article will not detail data leakage prevention policies and procedures, nor will it detail specific vendor solutions.
This article will, however, provide a brief overview of the ways data can leak and details the technological means of protecting yourself from data leakage.

Why is Technology Important?

Let’s start with a question: What do the following individuals have in common - an underpaid developer in an off-shore software house who sold millions of code lines to competitors, a well paid employee who stored client files on his stolen laptop and an extremely well-paid manager in a governmental organization who decided to post two CDs on the Web containing data about millions of British citizens (including date of birth, addresses and back accounts)?
The aforementioned cases did not lack a data prevention policy – the organizations did have well-defined data leakage prevention policies and procedures – however they did lack technological means to enforce these policies.

Technology without Policy

Don’t get me wrong, policies are part of my bread and butter. Without well-defined and management approved policies there will be no legitimate reason to have technological tools in first place. Policies define which one of these digital streams is considered sensitive information and who is allowed (or not) to access and handle this information.
The Ways to Leak Data are Limitless
I will assume that our internal network and data storage are as secure as possible. In this case, there are only two ways to remove data from our stronghold:
  • Physical removal (such as hardcopy of softcopy on media such as CD/DVD, USB, etc.)
  • Electronic means (dial up, Internet, FTP, SCP and every other existing way to transfer information).
From here, there are endless variations of each method.

How to Protect Yourself
There are many tools and solutions out there, but as I mentioned before this article will not go into detail on the solutions. There are a number of locations where we can detect the leakage and prevent it:

1. The Inner Circle
This is the best place to start. It is very tricky to prevent physical removal of information, but we can make it really hard for someone to try. So, why not limit access to the data in first place?
Many solutions exist to tackle this one. In my opinion, Role Based Access Control (RBAC) is the best approach to allow legitimate use of the sensitive information for business purposes while denying access to another.

2. Everything in Between

Here is where we need to think how to prevent data leakage. As I mentioned before, it is no simple task to prevent intentional or accidental leakage of sensitive data.
First, we need to make sure that all the hardcopies will be destroyed before leaving the premises. For that, we need to make sure that shredders are available and easily accessible.
Second, discontinue the use of writeable CD/DVD drives on your client systems. There is normally no reason for the average user to burn CD/DVDs. Furthermore, disable USB/Firewire storage and removable media. You might want to set up a number of stations where it will be possible to write CD/DVD, however limit access to managers or someone with higher privileges in order to filter the data leaving the organization.

3. The Outer Perimeter

Firewalls are our outer perimeter protectors. Usually, they are configured to block incoming traffic, however they allow most of the outgoing communication. This is also the best location to place a proxy server that will inspect all the outgoing traffic. Based on predefined rules (that is where policies come), a proxy can decide which data can leave the organizational network and what should stay in.
But even in organizations where a proxy is used to scrutinize outbound traffic, there are many additional services that are permitted through the firewall which are not inspected by the proxy. We can use NMAP (nmap –sT –p 0-65535 ) to map all the authorized ports through the firewall in order to get an idea of the existing potential areas for data leakage.
The most common way of bypassing a proxy inspection is to use an SSH port, which is usually open for administrative tasks. Users can easily tunnel anything they like over SSH. Also, as I mentioned before, just because the default port for SSH is 22, it doesn’t mean the SSH cannot run on any other port (such as over 80 or 443).
Additional methods include DNS or ICMP Tunneling. For example, tools such as OzymanDNS, NSTX and DNScat allow tunneling SSH traffic over DNS (and other protocols). In many cases, it is impossible to block a DNS protocol altogether, but for example, you can use internal a DNS server and allow DNS traffic only from that specific server through the firewall.

4. The Wide Wild West

In those rare cases when we do need our sensitive data to leave the protective walls of our organization, we need to make sure that the data is sufficiently protected. Believe me, using a ZIP file with ‘1234567890’ password (and that is a long password) is not considered protection at all. As an alternative, you could use PGP (of GnuPG) to encrypt your files with recipient(s) key(s) and then either write the data to CD/DVD or send it using electronic means, such as Email or Bittorent. Even in a case when CD/DVD will be lost, you can sleep quietly due to the fact that it is currently impossible to break an RSA1024 bit key (this is a minimum standard for today’s encryption).

Introducing a good set of organizational Data Leakage Prevention policies is not enough. On the other hand, technological solutions are meaningless without a good set of policies since you need to define what is allowed and what is not.
Technology is a necessary ‘tool’ to backup and enforce policies and in order to limit data leakage in an organization (it would be unwise to believe that it is possible to prevent data leakage altogether). A good combination of both technologies and policies is needed.

Published under Comsec Consulting UK

No comments:

Post a Comment