LogBlog

« February 2009 | Main | April 2009 »

Are Network Sniffers for Database Audit Irrelevant?

Nick Selby, Research Director for the Security Practice at The 451 Group wrote in a recent Impact Report on Guardium:

The majority of customers in the past six months to one year have been buying Guardium's agent-based product, which it calls an S-TAP.  We've discussed the technical approach of Guardium and its agent before. After speaking with scores of customers and tire-kickers, we can say it's hard to explain. But demonstrably, there is an enterprise appetite for agents as opposed to network taps for this kind of product.

Also, Tizor, a  network-sniffing based database monitoring solution was sold off to Netezza for a meager $3 million.

These two events prompt me to ask : who still cares about a network-sniffing based approach to database monitoring?  It appears there is many reasons to by-pass network-based monitoring all together and to go straight for the best (and least intrusive) database agent you can find.

First there were native audit logs to monitor database activity.

Then the industry decided that perhaps this was not a good idea:

a) Writing logs for every transaction can slow down the rate at which to write transactions.  Most databases are IO bound after all.

b) With database administrators having the ability to turn native audit on or off, the fox is watching the henhouse.

c) Without an agent, there is limited to no ability to block suspicious (trans)actions.

To accommodate these concerns, database monitoring by sniffing the network was born.  That seemed like a good idea: deployment was (or seemed) quick and no impact on the database performance.  Then reality set in.  There is a lot of information that you miss if you only sniff the wire:

a) You miss encrypted transactions

b) You miss local access

c) You miss encrypted, obfuscated, or dynamic queries and stored procedures and triggers

In response to these limitations, a first generation of database agents was born: host-based OS agents .  Unfortunately these agents were really an afterthought for network-sniffing focused vendors and - as is often the case with first generation products - these OS agents have some short-comings as well:

a) OS agents are implemented in Kernel mode or as a device driver on Windows thus very intrusive and if it crashes it can bring the machine down (fail close).

b) OS agents completely rely on the appliance for analysis. Without it (offline, unplugged) there is no policy enforcement and no alerts.

c) OS agents in most cases help to cover local connections but still does not give you full, in-depth visibility into encrypted, obfuscated, or dynamic queries and stored procedures and triggers.

d) OS agents available today need the network component to help terminate connections (TCP reset), which is a very course mechanism to block transactions that results in many false positives and thus hurts productivity.

However, what IF you could overcome these shortcomings and design an agent that is:

a) Light-weight, typically consuming less than 5% of CPU cycles - knowing that most databases are IO bound, not CPU bound to begin with.

b) Has high visibility into local access, encrypted, obfuscated or dynamic queries and stored procedures and triggers, as well as access to system tables.

c) Has granular blocking abilities, including automated connection termination and connection  quarantine, based on granular policies, including specific database objects, SQL statements, User ID, Source IP address or applications used.

IF you had this type of agent, would you still need a network sniffer?  Why bother?

Posted March 09, 2009 in | Permalink | Comments (0)

« February 2009 | Main | April 2009 »

Legal Lessons From a Computer Fraud Case . . .

A recent ruling by a Federal court in Georgia in the Andritz, Inc. v. Southern Maint. Contractor, LLC case held that lost revenue caused by theft may not be recoverable under the Computer Fraud and Abuse Act. This means to me that if you can't stop an ex-employee from stealing information from your systems in the first place via proper de-provisioning and auditing tools, you may be out of luck in terms of recovering lost money caused by that theft.

The lawyers at Wilson Sonsini Goodrich and Rosati wrote an interesting alert about the ruling, which has also been quoted by other bloggers such as Tom Kemp's blog at Centrify.

The bottom line for the lawyers?

1) Make sure you have enforceable non-disclosure and  non-compete agreements with all employees who have access to  sensitive company information can strengthen claims.

2) More  practically, companies may want to consider how they monitor  and enable access to such information and ensure that access  is promptly terminated when the employee departs.

3) Finally, the  presence of or access to tools that enable analysis of user  activity, including log-file management, can help employers  evaluate whether or if any such unlawful access has occurred.

Posted March 04, 2009 in | Permalink | Comments (0)

Visit loglogic.com

I ♥ Logs

Subscribe to this blog’s feed RSS

January 2010
Sun Mon Tue Wed Thu Fri Sat
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            
Categories
Archives
Blogroll
Blogroll
Compliance
Good Reading
LogLogic
LogLogic Partners
Sites We Watch