Newsletters




Protecting Data at the Source - Q&A with Application Security’s John Ottman, Author of ‘Save the Database, Save the World’


Bookmark and Share

Despite highly publicized data breaches, ranging from the loss of personally identifiable information such as credit card and Social Security numbers at major corporations to the WikiLeaks scandal involving sensitive U.S. Department of Defense and U.S. State Department information, and the "alphabet soup" of compliance regulations, data around the globe remains at grave risk, according to John Ottman, president and CEO of Application Security, Inc.,  who has written "Save the Database, Save the World" to focus attention on the problem and present steps to its solution. While super secure networks are important, that alone is far from enough and a layered data security strategy with a commitment to  "protecting data where it lives - in the database" must be pursued to avoid risks posed by outside hackers as well as authorized users, says Ottman. A stronger government hand may be needed as well to defend "the critical infrastructure that operates in the private sector," he suggests.

A core premise of your book is that when data stores are compromised, our society is at risk. How safe do you feel data stores are at this time?
Ottman:
We believe that less than 10% of the world's databases are locked down with database security, risk and compliance solutions. There are seven and a half million databases out there, and probably less than 10% of them are actually locked down, so it is a big gap.

There are always new solutions and stricter regulations covering data governance and yet new threats continue to emerge. Do you feel that we are making headway or losing the war against data security threats?
Ottman:
We are definitely losing this war.  There is research that came out recently from Verizon that says that in the last 3 years more than 519 million records have been breached and over 92% of those records came from databases. Clearly, the problem is getting worse, and clearly, as an industry and as a society, we are failing to protect sensitive data.

In the book you bring up the point that many approaches are network- or perimeter-based and not really centered on the database. Is that the main problem you see with current data security approaches?
Ottman:
That is probably the biggest issue. We have spent, as an industry, as a society, billions of dollars over the last 15 to 20 years on building security solutions for our infrastructure. Almost all of that has gone into network- and perimeter-oriented approaches. We have done some work with operating systems and spam and things like this.  But it has really been focused on perimeter- and network-based security solutions and as our research shows, only 10% of databases have gotten that kind of focus so our message is that you have to protect the data where it lives - in the database.  It is kind of like a bank locking the front door and leaving the bank vault open if you don't deal with the issue of database security. 

Does the focus on database reflect a new reality in data security?
Ottman:
Originally, it was all about keeping people out, but what we are finding today is that the insider threat is the largest source of breach, and credentialed users are actually attackers. We didn't go into the problem that way. We went into the problem believing that if you are a credentialed user, there is not going to be a problem. No better example debunking that is the WikiLeaks disaster. That is a perfect example of the problem where it is not an outsider threat, it is an insider threat.

You cite statistics from the Verizon 2010 Data Breach Report that the percentage of data breach cases that involved insiders rose to 48% in 2009, an increase of 26% over the previous year. Do you think the WikiLeaks case succeeded in focusing attention on the risk to data security posed by insiders?
Ottman:
I do. Just recently, McAfee published an article saying that 41% of companies are planning to purchase database activity monitoring. That is a great sign.  Really, the book is all about putting a face on this problem. It is one that poses different technology challenges and requires different skill sets than network- or perimeter-based security. What we are trying to do is educate everyone on what database security is all about - what are the challenges and what are the solutions.

One of the key findings in recent research studies done by Unisphere Research and sponsored by Application Security among various database user group members is that many of the challenges to data security are often not technical, but organizational, and that there is a disconnect that exists in organizations around awareness of security measures being taken and the funding available to support them.
Ottman:
From an organizational perspective, typically security issues are handled by CISO teams. They typically have network or operating system skill sets.  When you are talking about database security, now we are talking about the DBA organization and the DBA organization hasn't traditionally been brought into security. And, quite frankly, when the DBA team has been brought in, it has been problematic. The native auditing systems of the databases have been plagued with performance problems, and it really turned off database administrators to the concept of auditing database activity. And so, there is a kind of a skill set mismatch. Security guys have not traditionally been involved with databases and applications, and database administrators have not traditionally been involved with managing threats - certainly security and compliance threats on this scale.

Are there other issues with DBAs overseeing database security?
Ottman:
Obviously, a database administrator has universal access to the database and we have to have somebody who has universal access to manage the database. But the most common database security audit filing is a separation of duty violation, where database administrators are deemed to be privileged users who should have compensating control. In other words, it is theoretically possible for a database administrator to turn off audit and logging, do something to the database that might be nefarious - and then turn the audit back on, after they are done, so there are no footprints.  That is a very typical SOX audit finding. And database activity monitoring is a pretty standard solution to resolve that. I think part of the issue is that the suggestion there is that database administrators are somehow the problem.  Database administrators are actually the solution and there should be no thought of demonizing database administrators. They are critical to the solution set.  But - compensating control of people who have privileged access to sensitive data is a critical issue in many regulatory filings.

Is the emergence of "big data" adding to the strains on organizations in terms of their ability to manage and protect their databases?
Ottman:
First of all, there is just more and more sensitive data that is being collected. And, when you have enormous volumes of data that need to be audited you can no longer consider doing it manually. In the absence of database security solutions such as ours, database administrators might be asked to go through an audit log manually, and the bigger the database, the bigger the log.  So - manual solutions are just no longer practical as databases get bigger, and having automated security, risk and compliance solutions is really the only way to solve the problem

How do cloud deployments factor into this - are private clouds more secure, or less safe than, public clouds?
Ottman:
Everything that is necessary in a traditional environment is still going to be necessary in a cloud environment. Now, if you are talking about a private cloud environment, what is going on there is that it is becoming easier and easier to provision databases.  Companies like BMC and HP have solutions where the provisioning of a database is automated so you are seeing a proliferation of databases because it is so easy to build them.  Sometimes they get decommissioned and maybe that is not all the time, and so you have questions of orphaned databases in large private cloud networks and I think that poses some additional problems. In the public cloud, we have got a whole new set of architectures for databases. For instance, Database.com or SQL Azure offer a completely new way of doing databases and those architectures today actually lack a lot of the basic security features such as database activity monitoring or rights management of privileges. Those features in public cloud architectures are something that have to be brought forward. And in private cloud architectures, there is just proliferation and that makes the problem bigger.

You talk in the book about the problem of database SRC thus far being driven by industry self-regulation. What is the alternative?
Ottman:
A perfect example is HIPAA. HIPAA has been around for a long time, and it was not until the HITECH Act, which came in right after the Obama administration took office, that there was actually an enforcement provision behind HIPAA. Essentially they were saying that you have to protect people's healthcare information from being disclosed but if you don't, nothing is going to happen. So, as a result, people just did not get mobilized on the problem. Now, recently, the first couple of enforcements of HIPAA have happened. And for HIPAA to have been around all these years and there only to be enforcement just very, very recently in the face of a tremendous amount of HIPAA data breaches, it kind of tells the story. Organizations don't always do what you expect them to do. And, I think that enforcement provisions in these regulations are lacking today.

What needs to be done?
Ottman: I think that as a society if we really want to expect that our personally identifiable information will be protected, there has to be enforcement. PCI is an industry self-regulated approach and some organizations take PCI very seriously, and have robust environments. And many others don't. It really depends on the point of view of the management of a particular organization as to whether or not they are going to take PCI seriously. Even the biggest enforcements in response to PCI violations have not been that big.

Are you concluding that the U.S. government needs to become more forceful in protecting data, or forcing organizations to protect data?
Ottman:
I think there is no question that this is an area where the welfare of the public needs to be supported by more regulation from government organizations.

And how would that take place? Do you see that happening in the near- term and which government agencies or departments do you see taking on that role?
Ottman:
I don't know if I have the answer to that. But I think the model on how to do it might be FISMA [Federal Information Security Management Act]. FISMA regulations are based on a law that federal government agencies must put protections in place based on NIST [National Institute of Standards and Technology] 800-53 guidelines. I think that that is a good model for how enforcement of regulations could be put in place. How it is actually administered or policed, whether it is the Department of Justice or the Department of Homeland Security - probably different regulations are going to apply to different types of organizations and the actual enforcement agencies may not always be the same - but I think the NIST 800-53 framework is a good one that has been put forth to support FISMA and I think that it is a good model that can be extended into the private sector.

Since that oversight and enforcement may take some time to be put in place, what is your advice for organizations on steps they should take to secure their databases?
Ottman:
There are steps that organizations can take right away. They can put vulnerability management programs in place to first understand what the scope of their security profile is. Many organizations do this already, but not enough.  A vulnerability management program starts with discovery so you know how many databases you have. Most CIOs if you were to ask them how many databases they have, don't even know; and, of course, it is impossible to protect databases when you don't have an accurate inventory of how many databases you have. And then, what are the specific vulnerabilities of each database - weak passwords, patch gaps, configuration vulnerabilities? That is what a vulnerability management program can do. 

The second thing is start doing a better job managing rights and privileges, and implement entitlement management programs within your organization so you can start to deal with the problem of who has what access to sensitive data in your organization. And then, finally, we are seeing tremendous activity in the area of database activity monitoring. This is a low-impact approach that is typically managed by a DBA organization to provide a compensating control for activity monitoring of a database, so you don't have to use the native audit which can be a performance hit on your database. Database activity monitoring systems are less intrusive and very effective ways to make sure you can know exactly what is going on in your database at all times, and have a reliable audit record of all activity.

For more information about the book, go to www.savethedatabase.com.


Sponsors