Database Security 3.0

Patch 'em up, Patch 'em up....

By Josh Shaul

Every couple of weeks I hear a complaint from a DBA that they have been flagged for a security violation for not running the latest database patch. It usually goes something like:

“I got written up for a high-risk vulnerability because I’m running one or two patches behind the database vendor. I think it’s unfair and more to the point just plain wrong. I checked out the readme files for the missing patches, and there is no listing of any security fix at all, or at least not one that applies to my system.” 

At first glance, this sounds like a pretty solid argument. Why should someone get written up for a serious security violation for missing a patch when it appears that the patch has no security implications? The problem is, sometimes a patch is more then it appears or claims to be. Database vendors, actually nearly all software vendors release patches for their software periodically. Generally there is some description of the patch, what it’s for, etc…. The part that most folks don’t realize is that software vendors make no promises about fully disclosing what changes go into each patch. Some companies choose to document all changes, however most choose to document only the changes that are directly related to issues reported by customers. Issues uncovered internally are generally patched without any notice. This includes both functional bugs and security vulnerabilities.

There was recently a good example of this with an Oracle July 2008 CPU. In that CPU at least one undocumented issue was fixed, a flaw with Database Vault that allows a DBA to bypass the vault protections and gain access to all the data in the system. If you’re not familiar with database vault, it’s a special kind of Oracle database designed to segregate database management from the data being managed. Basically it’s a tool to keep DBAs from looking at sensitive data in the database. The flaw that Oracle corrected made it trivial for anyone with DBA rights to gain access to any data in the database. 

This is important to know about. The vulnerability Oracle fixed is a fairly big one….but it only impacts data vault. In the grand scheme of things, for the database community at large this was a fairly minor issue. Maybe that’s why Oracle chose not to document it. Not enough deployments of database vault to make it worth their while? Embarrassing to fix a vulnerability in a security bolt-on for the database? Who knows. Thing is, if you’re running database vault to protect your organization’s crown jewels, I’m sure you would want to know about this issue. Otherwise you may choose to skip the patch….and that’s really the point of this post. 

Those complaints that I get about missing patches causing security violations always get the same response: “You can’t trust the vendor to fully disclose what a patch fixes, so you should assume the worst case and patch if you want to ensure your systems are protected.” That’s the bottom line. Missing patches, no matter what the readme docs may say, should always be viewed as a security violation. Not doing so leaves you open to get bit on the you know what……. 

So if Oracle didn’t disclose the vulnerability or the fix, how do we know about it? Well, there is the folly of the partial disclosure approach. Some smart security researcher  (Alex Kornburst) found the vulnerability on his own. He reported it to Oracle, and they responded by telling him that this was a known issue that was (silently) fixed in July 2008 CPU. Oracle is getting better about this kind of stuff, but they still have some room for improvement. I hope that as their security processes continue to grow, that they’ll become much more open about what security issues they are fixing with each patch.

It’s got to be a little embarrassing when one of these “secrets” gets out. Oracle has taken so many big steps to improve their perception about being very serious about security (no doubt Oracle is VERY serious about security)…but when this kind of thing happens, it reminds folks of the dark days when security issues were swept under the rug, and that’s not good for anybody…… 

Interested in learning more? Check out Alex’s blog post about this and another issue with database vault:

http://blog.red-database-security.com/2008/11/21/oracle-database-vault-privilege-escalation-exploit-published/ 

Happy New Year everyone!

 

 

 

And the Survey Says......

By Josh Shaul

This week we released the results of our “Database Security Controls” research study, which was run for us by the analyst firm Enterprise Strategy Group (ESG). We sent ESG off to interview global IT decision makers located in North America. They met with 179 companies and asked a set of questions around data and database security. The responses were collected and aggregated for the report. The results are simply astonishing.

A whopping 84% of respondents believed that they have adequate protection in place for sensitive data.

With so many data breaches reported this year, we were surprised to hear that so many folks felt comfortable with the controls they have in place….but if 84% of companies really have adequate data security, we’re all in pretty good shape….Right?

The survey then drilled down into more specific questions. Have you failed an internal audit? Have you failed a compliance audit? Have you experienced a data breach recently? The answers to the specific questions painted a very different picture. More than 50% of the organizations surveyed experienced a data breach in 2008. I repeat, more than 50% experienced a breach this year, while at the same time, 84% claim to have adequate security. Adequate means enough to get the job done…..Right?

And it’s not just data breaches.

48% failed internal audits. 42% failed payment card industry audits. 38% of federal agencies surveyed failed FISMA audits. The number of failures present a huge problem on their own, but couple that with the false sense of security that the IT community has built around its data, and we really have something to worry about. The amount of data at risk is staggering. For those of you who have experienced a data breach this year, or who regularly fail key components of your audits, stop feeling secure. If you haven’t done something drastic to correct the situation, you’re likely a soft target just waiting to be spotted.

There are signs of hope.

There were some real signs of hope within the survey results. 76% of the organizations we spoke with said that they plan to place purchasing priority on database security solutions in 2009. Wait, didn’t 84% say they already had adequate security?? Maybe folks aren’t burying their heads in the sand after all.

Grab a copy of the survey results from our webpage.

Beanbags and Database Security. A discussion at CSI 08.

By Josh Shaul.

The week before Thanksgiving I led a session at the CSI 08 conference in Washington, DC. It was setup as a group discussion in a small room with bean bags instead of chairs. It was a relaxed atmosphere designed to foster a philosophical discussion. In reality, there was one row of chairs at the back of the room. Everyone except one or two folks sat on chairs. The bean bags were a little intimidating. Once you sit in one of those things, there is no telling if you’re ever getting up. 

Decision Making - The Stakeholders

Our discussion was an exploration of who the stakeholders and responsible parties are in a typical corporation’s database security program. We started by reviewing a few recent data breaches, discussing how they happened and could have been prevented. With an understanding of the mechanics of a data breach, we began on discussion on responsibilities. 

It quickly became clear that not everyone in the audience knew of a database security program at their office. Some even came clean, admitting that they have no such program or effort. Those who did have a plan in place discussed radically different approaches and experiences.  

Group Authority?

A security manager at a large retailer described how his team was responsible for ensuring that databases and other applications are configured securely; in accordance with the requirements of internally developed standards. That was the good news. The bad news was that his group was not responsible for making sure databases had security patches applied. That was someone else’s responsibility. His group was also not responsible for auditing access to databases or monitoring for attacks. Those activities would also fall into other groups….if they were in place at all…he wasn’t sure.

Split up Responsibilities

Another member of the audience described that they have a policy that mandates some basic database security requirements such as strong passwords and access controls. The policy is fairly solid, but there is no one responsible for ensuring that the policy is implemented. Some systems are likely in compliance, others are not. The only people who have a chance of knowing are the system owners, and the scope of their knowledge is very narrow, they only know about the systems they personally own and manage. 

Clear ownership, No ownership

We also heard from a utilities company where there is clear ownership of policy development, and database assessment and auditing, but nobody responsible for remediation or risk reduction. This group made an investment in technology and processes to measure their security posture, but gain very little return from that investment because they rarely fix the problems they find. 

Does anyone own database security? 

According to the group I met with, no one person ultimately does. It boils down to a shared responsibility between operations teams (database admins), IT security teams, and often audit / compliance teams. The group agreed that picking a vocal leader for each of the major functions of a database security program (policy development, assessment, auditing, monitoring, and remediation) is a critical step.

Ensuring that the leaders communicate and cooperate, and are held accountable when their functions don’t deliver is the ultimate key to a successful program, but is often the biggest hurdle to overcome.