by Maarten Van Horenbeeck

Just yesterday I was reading an article on extrusion detection and information theft on a large information security portal. After the article, I had a quick look at some of the questions in their 'pop quiz'. This one stood out the most:

Which of the following could not be used as an open source extrusion detection tool?

1. Snort (in inline mode)
2. SnortSam
3. L-7 Filter
4. FWsnort
5. Encase Enterprise

Encase Enterprise would make a poor 'open source tool', given it's in fact closed source. The sad thing is however that Encase Enterprise could actually be of just as much use in preventing data leaks from your organization. A bit of a poor question indeed.

Admittedly, Snort is a cool tool of identifying known inbound attacks and even protocol anomalies and violations, but that's where it ends. Snort could also come in useful to identify data returned through blunt SQL injection or malformed queries. If I do a

a';SELECT * FROM creditcards

And this would not be picked up by the inbound IDS, Snort could usefully trigger on a:

4417 1234 5678 9112

So it's at least a valid component in the system. As soon as I have the ability to execute arbitrary code execute on the target database or web server, or have the ability to format the straight SQL query output, the picture changes. I won't be sending through the value above, but I'll be sending through something like this:

A4417123B45678C9112D

I might even be compiling it in a file locally, sending it through in one encrypted batch. If I'd like to get really nasty, and the organization is using a solution which verifies the check digit, I would probably add one to each value to make the false positive check fail.

Evasion of data leaks is, as such, a bit of a given. We can verify outbound traffic for a) things we know, and b) things we don't expect. That's about it. But there's a large gap in between. There are many things we would know as humans, but our machines could not logically be expected to identify. One example is an MSN session in which an internal user passes on a credit card number to an outsider. He could change it any way logically possible, something a machine will never be able to fully evaluate.

Most of the tools listed in the site's question above, as such, would only be helpful when we're dealing with actual compromises. People who are breaking into systems and generating traffic that is not expected, or specific return strings of attacks that could logically be expected. From that perspective, I'd say Encase Enterprise, with its eDiscovery functionality, could probably do just as good a job on the insider threat. Regularly image user machines for compliance verification, and if they have credit card numbers or HIPAA Personally Identifiable information on their machines, make a strong statement that such neglect will not be tolerated. As protection against data leakage, the second measure would probably be much more effective.

This latter issue is however where actual Extrusion Detection/Data Leakage vendors step in. These solutions can be deployed on enterprise level components (desktop, database server) to measure at what rate information is extracted from knowledge systems. A single desktop of someone in accounting who suddenly opens more than two or three client accounts would be suspicious. Someone dumping the database locally would definitely flag an event. Some of these could even be implemented as triggers in the database application itself, if the data 'on disk' is encrypted.

Naturally, deploying an agent on each system in the enterprise isn't necessarily a sound idea without some assurance from the vendor.