LogLogic has expanded into the Database Security market: you can see a screencast of LogLogic Database Security Manager here.  LogLogic has offered the ability to collect, store and analyze native database logs for years (via our standard log management platforms), so what's new?  Here are five good reasons for customers to implement a specialized database security product and to integrate this with your a broader log management solution:

1) Databases are so important they require specialized attention

2) Any successful breach of a database is very bad news (expensive)

3) Databases are especially vulnerable to attacks

4) Native logging for databases can be a bad idea

5) Database security point solutions are incomplete

Databases are so important they require specialized attention

Companies globally spend in excess of twenty billion dollars each year on their database infrastructure and thus it is wise to spend 5-10% of such investment to manage and protect your investment.  Databases also house the most valuable information in your business: customer data, transaction records, patient information, etc.  Databases are mission critical and power your front-line, revenue generating applications - such as claims processing, credit card transactions or trading systems. 

Any successful breach of a database is very bad news (expensive)

Databases are the one-stop shop for valuable information.  If you lose a laptop, the information may be abused (or thiefs wipe the laptop clean and sells the gear).  Even if the information falls in the wrong hands, there are likely only a small number of records stored on the laptop.  However, all records are available in the database and if somebody attacks and penetrates your database, it is virtually certain there is ill will.  It is good business for organized crime.  Each customer record is worth $200 and the average database attack costs $6 million (the Ponemon Institute).

Databases are especially vulnerable to attacks

Many database administrators do not apply the latest security patch in a timely fashion.  In order to apply a patch, it has to be tested with all applications accessing the database and the database has to be taken off-line in order to apply the patch.  Downtime for a critical business application is expensive so security is compromised in exchange for availability.

Native logging for databases can be a bad idea

For databases, performance is everything.  More transactions means more top-line.  Therefore, many database administrators refuse to turn on native audit logs.  Databases tend to be IO bound and writing a log for every transaction can deteriorate database performance by as much as 20%.  There are also some attack patterns that are hard to detect from native logs - such as those that make use of triggers, stored procedures and such.

Database security point solutions are incomplete

For all the reasons above, dedicated security point solutions emerged to offer an alternative to native audit.  Some of these are based on sniffing network traffic, but most use a host-based agent.  Only a host-based agent can see all database activity including local access and encrypted queries.  However, database activity is best analyzed in the context of all other activities by a particular user (or system) - such as VPN access, application activity, and e-mail traffic for example.  You can achieve such contextual analysis by integrating your database security product with a broader log management solution.

In a recent video-interview, Mark Nicollet from Gartner recommends that customers should consider buying Database Activity Monitoring and Log Management/Security Information and Event Management from the same vendor.  He also talks about the drivers for Database Security technology in general and about the benefits of a host-based approach to Database Activity Monitoring.  You can watch his interview here.