Threat Level: green Handler on Duty: Xavier Mertens

SANS ISC: Poor man's DLP solution - Internet Security | DShield SANS ISC InfoSec Forums


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
Poor man's DLP solution

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

Manuel Humberto Santander Pelaacuteez

185 Posts
ISC Handler
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.
Anonymous
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.
Anonymous
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.
Hal

50 Posts
I would think a network sensor triggering on plain text strings would be easily defeated by compression/encryption.
Hal
9 Posts
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.
Hal
3 Posts
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.
Hal
3 Posts
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.
Hal
12 Posts
@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.
ChaudRO

1 Posts
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.
Mysid

146 Posts
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.
Mysid
27 Posts
@Omar - you have a point but the article specifically mentions stealing information through e-mail and file transfers. Anyone on the inside could encrypt/compress a file and transfer it out with this sensor being none the wiser. Malware that exfiltrates data routinely encrypts specifically to defeat this kind of approach.

I think something possibly more useful would be to monitor where outbound connections and data flows are destined. A lot of data headed to some consumer ISP in Normal, IL (possibly an intermediate hop) might be more of a red flag than an all clear because that data doesn't appear to contain any key words.
Mysid
9 Posts
Create logically separate networks via rfc1918 space and proxy everything. Verbose log or packet capture all network traffic to allow retroactive searches for sensitive data.

Encrypt your traffic on the egress only and block/flag anything encrypted that tries to get out.

Check out the new free DLP module in the latest ClamAV. Its pretty spare but works surprisingly well.
Mysid
5 Posts

Sign Up for Free or Log In to start participating in the conversation!