Q&A: 'Save the Database, Save the World' Author Talks DB Security Lifecycle

The IT industry may be finally starting to fully embrace the idea that it needs to better protect information within the database, but it's going to take a lot of cultural change and hard work before organizations create a functional model for database security, says John Ottman, CEO for database security firm Application Security Inc. and the newly minted author of "Save the Database, Save the World." In the book, Ottman lays out a case for instituting a holistic strategy for protecting information "where it lives" and discusses the people across IT who need to get involved in making that strategy a reality. Dark Reading caught up with Ottman to discuss his rationale for writing the book and some of the pressing issues he uncovered through his research.

Why did you decide to write this book?
Ottman: Our research shows that less than 10 percent of the world's databases are currently locked down with database security, risk, and compliance software, and I think that's a frightfully low number. The whole industry, which includes vulnerability assessment, rights management, sensitive data discovery, policy management, and encryption, is probably somewhere between $200 and $250 million in 2010 revenue.

But if you do the math on all that, what you find out is the penetration of database security into the database market is like 7 percent. You have 7.5 million databases out there in the world and very few of them have this software deployed.

The book is putting a face on the technology so that people can understand it in plain terms. It's not overly technical -- it's for the business people who understand technology so they can understand why this stuff is important.

Can you discuss how the current network-based security approach at most organizations is hurting their data security?
Ottman: If you look at the history of the IT security industry, over the last 15 years or so billions of dollars have been spent, mostly on network, perimeter, and operating system security approaches. And despite that massive, massive investment, the number of data breaches just continues to grow.

The Verizon report talks about 420 million records breached in the last two years, 92 percent of which are from the database. And so there's a real message there that despite the fact that we've built these super secure networks -- and to be sure, we had to do that -- it's not sufficient to protect sensitive data. The statistics and the data on breaches are irrefutable that the problem is getting worse.

As an industry and, frankly, as a society as a whole, we've got to admit the fact because the stats speak for themselves: that the problem is getting worse, and we're essentially failing to protect sensitive data today.

And why is that? It's because we're not protecting the data where it lives: in the database.

In your book you discuss the database security, risk, and compliance (SRC) lifec ycle. Why is this life cycle so important?
Ottman: Database security today looks a lot like ERP technology in 1980, with people buying best-of-breed point solutions for different problems. It was a big job to pull it all together, and you didn't really have a single version of the truth of financial information. You had multiple databases that had to be integrated together.

The state of the database security industry is very analogous to that today. You've got a lot of companies that have come to the market with point solutions, whether it's database activity monitoring, vulnerability assessment, rights management, or sensitive data discovery.

As a result, CISOs and security engineers are forced to integrate all this stuff together themselves. So how to bridge that gap? I think the answer is we've got to get away from the point-solution mentality and we need to think about database security, risk, and compliance as a life cycle, a process-oriented approach to continuous compliance and ongoing security.

All of these separate applications are all very interrelated, and you must have a life cycle approach of integrating these applications together if you really want to lock down a database.

What would you say are the biggest mistakes organizations are making right now in regard to database security and locking down data, in general?
Ottman: It's very typical that an organization might go through a SOX audit and have an audit finding that they don't [have] a compensating control for database administrators and that their privileged users must be monitored. I think the biggest mistake is that people jump right to database activity monitoring without going through the rest of the life cycle.

So if they haven't done a discovery, they don't know all the databases that they have. If they haven't got a policy management environment, they may not have a complete ruleset to drive monitoring. If they don't have a vulnerability management scan, they may not be monitoring all of their vulnerabilities.

You see it with database activity monitoring all of the time, where people will not deploy the business context of what to monitor. Until you have that business context established of what and why and how to monitor, you're kind of shooting in the dark with database activity monitoring.

What kind of cultural changes need to happen within an organization to get from that point-solution strategy to a more comprehensive life cycle strategy?
Ottman: Well, that's a good question. I'm not sure I know the answer to that!

I think probably what would really help would be if security organizations lift up the cloak over databases.

You know, when you look at most of the skill sets within CISO organizations, what you typically find are people coming from the network world or the operating system world.

I think in many cases it takes security teams out of their comfort zones when they need to go down the hall and meet with the database team and tell the database team in a language that might be new to them on what their vulnerability issues are.

It's a new initiative for most security teams to be recommending security solutions for application and database organizations. Database organizations have typically been left on their own to look out for this issue, and now security teams have to engage.

So security teams have to have a skill-set upgrade to be able to be effective at working with people that are speaking different languages like SQL and stored procedures. They've got to know what these things are if they're going to be credible and be able to build a partnership with the database and application owners.

That segues perfectly into my next question: What is the DBA's role in improving database security?
Ottman: The DBA plays a really important role because a lot of the activity that's involved in database security, risk, and compliance needs to get handled by the database administrator. When vulnerabilities are discovered, it's the database administrator that has to remediate those vulnerabilities.

If you're going to monitor a database, it's the database administrator that needs to actually run the software that is going to be the monitoring agent.

Database organizations need to view security, risk, and compliance solutions as their friend, and I think that has not always been the perspective that the database teams have. When you tell a database administrator that you have a great idea, that you're going to put an activity monitoring system in place that's going to be able to track their every single move, it doesn't always leave the DBA feeling comfortable.

The reality is that database security, risk, and compliance solutions make a DBA's life much easier.

If you think it's a trouble to monitor a database with activity monitoring software, consider the alternative of manually poring through native audit logs in databases. Or if you're responsible for patch management of the database, consider the difficulty to really assess patch levels across a large population of databases manually.

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.