2008 DOI: Day 8 - Protect the Vault (that's where the money is)
2007 Incite: The Information Strikes Back
2007 finally brings acknowledgement that data/information security is different than protecting the network and servers. Yet, there is a major skills shortage in folks that understand how to protect applications and databases, resulting in accelerating interest in application and database security product offerings. But history will repeat itself, as a “fool with a tool” is still a fool, which doesn’t help customers solve any problems.
2008 Incite: Protect the Vault (that’s where the money is)
The hackers continue to go where the money is by increasingly targeting the databases storing private information. Database vendor’s disdain for security doesn’t help, and creates an opportunity for database monitoring and security solutions to gain a foothold before this capability is subsumed into the DBMS and/or network fabric. Encryption infrastructure makes little to no progress in 2008, despite regulatory pressures – largely due to complexity and the nebulous compensating controls clause.
In the second half of the application/data/information security Incite, let’s dig a bit into database monitoring and security. The hackers are a lot of things, but stupid isn’t on the list. They know the database stores most of the information they want, so that’s what they target.
Most organizations haven’t done much in terms of protecting their databases, mostly because they figured the attackers couldn’t really get to the database – so they focused on other things. Unfortunately they are wrong. External bad guys are very good at compromising web applications giving them unfettered access to the data store. Even more potentially damaging are the insiders, since they already have access to the database server, and from there it's not brain surgery to get access to the data.
Now you have auditors coming in and pointing out that very issue. So lots of the larger database security implementations have been a direct result of an audit finding, and the natural response follows – buy a product and make the problem go away.
This is another case where we’ve seen this movie before. I expect database security to continue rolling out like most other security functions. First came the scanners. Most organizations won’t spend money on solving a problem they don’t know they have. So the initial step is usually to do a vulnerability assessment on your databases. They are checking for vulnerabilities and configuration errors.
Next they tend to monitor what’s going on. Who is accessing what? Should they be there? What changes are being made? It’s the whole separation of duties thing. The auditors want someone to watch the watchers. So some kind of monitoring is usually the next capability that gets rolled out. Per usual, I have no dogma or religion about monitoring via an external appliance or a software layer on the DBMS. There are use cases for both models.
Finally there is blocking. If the device were to detect a clear attack, it wouldn’t be a bad thing to block it. Yet, this capability is very similar to IPS. A lot of customers have it, and a lot of them don’t use it. Not to overdramatize, but you need to be able to explain to your COO why a multi-million dollar transaction was blocked by the database security gateway. That doesn’t mean you shouldn’t be blocking anything, but you better make sure you are blocking the right stuff.
Like everything else (or so it seems), over time this capability is subsumed into the database and/or network infrastructure. But that “over time” will be measured in years, probably 5-7 of them. That gives the database security market plenty of running room over the next couple of years.
Yes, you will see consolidation. But I don’t think that will happen in 2008. The database vendors are still in denial that it’s a problem (or that their over-priced, under-functional solutions aren’t good enough) and the market isn’t big enough to make it a must-have for a big security aggregator. Truth be told, this is something that IBM and HP should have. It would be very complimentary to their application dev and security tools, and should be wrapped into big application infrastructure projects as a preventative measure. Net-net, this is not a stand-alone market for any length of time.
What about encryption? You can’t really talk about data/information protection without mentioning good ol’ crypto. There will be little change in the crypto business in 2008, if anything things may slow down a bit – given macro-economic headwinds and the fact that no one wakes up and says, “I gotta get me an encryption infrastructure!” So we’ll continue to see the same user and vendor dynamics.
Users will continue to not understand why they need an encryption infrastructure and the vendors will continue to focus on making encryption disappear in other application initiatives. And that's where is should be.
To wrap up, we are on a multi-year journey for customers to understand that protecting data is fundamentally different than protecting networks or even servers. 2008 sees us continuing to understand. We aren’t there yet, but we are getting closer.
Photo credit: sigma


Hi Mike,
Another great post, this is a big deal. I think there is a step before the vulnerability scanning step, and that is: figuring out which databases to scan. In practice, many companies don't even know where their sensitive data is stored, and they try to figure that out first. The DLP vendors tend to talk about catching confidential data as it zips around the network, but I'd guess that the broader demand is actually for their "data at rest" products (if offered) that scan file systems and databases to try to identify data that might be confidential. If you don't know that, you can't even begin to lock it down.
Note: I don't work for a DLP company. I bring it up only because I see it as a necessary first step in making all the other data monitoring products actually work.
-Rick Caccia (ArcSight)