Poor man's DLP solution

Published: 2011-03-03
Last Updated: 2011-03-03 12:29:05 UTC
by Manuel Humberto Santander Pelaez (Version: 1)
12 comment(s)

Although I have been fortunate to work with a company that handles large amounts of money and time to implement the security solutions typically get the latest technology solution, we also have companies that do not handle the same amount of money due to profit margin business in which they are located and therefore there is a greater rationale for the investment of monetary resources in those projects that are vital to the operation of the company. 

A risk that materializes more frequently in companies is the leaking of information and one of the most common ways to steal over the Internet is through various forms such as emails and file transfers. That means we need to have a sensor that is responsible for monitoring the Internet traffic inbound and outbound. To determine your position, we will outline a two firewall DMZ and place a snort sensor in the middle using linux and configured in bridge mode.

DMZ with IDS

Bridge configuration is pretty simple. Consider eth0 as the interface connected to vlan11 and eth1 the interface connected to vlan10:

ifconfig eth0 0.0.0.0
ifconfig eth1 0.0.0.0
brctl addbr sensor
brctl addif sensor eth0
brctl addif sensor eth1
ifconfig sensor up 

Now it is time to configure the sensor. Many companies manage document templates, which contain default information that can be used to catalog the information contained therein. You can use words like secret, confidential, restricted, and many others. Based on this template, we proceed to create the appropriate alert to block the transit of information to the outside. For the following example, we will assume as the internal ip address range 192.168.1.0/24 and also that the template for confidential documents relating to the company X provides the following sentence: "Company X - Confidential":

alert ip 192.168.1.0/24 any -> any any (msg:”Data Loss from inside the network”; content:"Company X - Confidential"; rev:1)

Another interesting measure, depending on the environment and the risks of the company, is to disable the USB storage devices. To do this task in Windows environments, disable all permissions to the following files used each time you install a USB drive:

%SystemRoot%\Inf\Usbstor.pnf
%SystemRoot%\Inf\Usbstor.inf

If the USB storage device is already installed, change the following registry key value to 4: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\UsbStor 

Do you have any other ideas? Use our contact form to share it with us.

-- Manuel Humberto Santander Peláez | http://twitter.com/manuelsantander | http://manuel.santander.name | msantand at isc dot sans dot org

Keywords: DLP IDS
12 comment(s)

Comments

Your alert should read
alert ip $home_net any -> $external_net any (msg:”Data Loss from inside the network”; content:"Company X - Confidential"; rev:1)

and you should define your external and home net:
var home_net [192.168.1.0/24]
var external_net !home_net

this will eliminate false positives if you are transferring documents with in your organization.
This will also allow your organization to receive documents with that content with out alerting.

If its one thing i have learned over the years. If an analyst sees false positives coming from an alert enough they will start to ignore that alert.
No USB drives /might/ work out okay for suits and clerks. As part of our security architecture, though, we have isolated developement and lab networks. If you take away all ability for engineers to transfer large files we might as well turn off the computers and dust off the abacuses and ledger books.
I would think a network sensor triggering on plain text strings would be easily defeated by compression/encryption.
With the DAQ module implemented and the utilization of afpacket in snort, it is not longer necessary to bridge interfaces.

This command will run snort & bridge interfaces eth0 and eth1
./snort --daq afpacket -i eth0:eth1

Just an FYI incase a deployment is planned by someone.
Another solution for mass storage devices for protecting the movement of data through USB is to disable writing to them but enable reading:

Open Registry Editor.
In Registry Editor, navigate to the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\StorageDevicePolicies
Create the following value (DWORD):
WriteProtect

and give it a value of 1.
If your engineers can take data back and forth to 'isolated' networks with USB storage devices then they're not really isolated. They just have a huge bandwidth, very bursty connection. Since they're obviously allowed to move data between the networks, why not implement an easier network-based method that doesn't inherently compromise your ability to prevent data leaks.
@Robert, I think the goal of this approach is to alert on unintentional transmission of sensitive information. As you point out, it can be "easily defeated" by people trying to do so.
It should probably be noted, the bridging configuration makes the sensor a bottleneck and single point of failure for the entire corporate network. A Linux server running a bridging config, cannot forward as many packets per second as a hardware firewall.

And there's no "failover pair" config for a couple Linux servers like there is for a good Firewall such as an ASA.

Should the network have a gigabit uplink, the sensor itself is a potential DoS risk, high packets per second rates will cause the bridge to fall over and drop lots packets, when without the bridge, the load balanced server(s) would have handled the aggregate load fine.

Why go for bridging?
Snort can sniff traffic, and you can plug it into a network tap.
Slightly OT: You can get fail-safe network cards that will simply bridge themself when power fails. I've seen them in Enterasys Dragon IPS.

Diary Archives