Musings on Database Security

It’s been a while since I’ve blogged. Hit a dry spell, I guess. Will try to post more frequently and about some technical issues as well. Anyway, I’m at the RSA conference in San Francisco for the entire week. It’s been a great conference so far with interesting keynotes and sessions. Also, a lot of evening receptions that basically give you an excuse to drink beer and wine

I visited the PCI reception on Monday evening which was a big success with many interesting conversations. Spoke with many security managers from large organizations about PCI. It turns out that 99% of the people I’ve talked with are either in the midst of a PCI audit or have just undergone one. Interestingly, when asked about database security, most of the security managers I’ve talked with are saying that this is the next thing for them to invest in.

On Tuesday evening, I went to the SC magazine awards gala. My company (Sentrigo) was nominated for “Rookie security company of the year” which is very important to me and shows the security industry’s recognition of the importance of database security. And the best part of the evening was that we actually won!!! It was amazing being called to the stage and later interviewed for the magazine. I felt a bit like at the Oscars… Sorry about the poor image quality…

The only problem with the conference so far is that I actually don’t have enough time to go to all the sessions and keynotes I would like to go to. Too many meetings, I guess…

Next week, I’ll be presenting at Collaborate08 in Denver under the auspices of IOUG - if you’re around come and see me on Monday, or catch me later at our booth (#1826) in the IOUG section.

The rumors about my death have been greatly exaggerated, to paraphrase Mark Twain. I guess I’m a burst-blogger, at least for as long I’m also the CTO of a growing start-up.

The credit card companies started to make good on their threats and levy hefty fines like this one issued against TJX and its banks. This makes the pain of non-compliance very real, and I think we are going to see more of it as the credit card companies demonstrate that they mean business. This is one of the benefits of having an industry-regulated standard as opposed to laws and regulations - the incentives to enforce are business incentives, so they work…

A-propos, another recent development around PCI, which I think has not been receiving the attention that it should, is the passing of the first state law to augment PCI DSS the standard. Minnesota, the state that passed this law, is home to some of America’s largest retailers, such as Target and Best Buy, so on its own this law may have far reaching impact. Moreover, similar to California Senate Bill 1386 that deals with privacy breach notification and spawned copycat laws in some 38 other states, I expect the Minnesota law to be the harbinger of additional state laws (Texas, Massachusetts and Illinois are contemplating it), although in California it was shot down by the governator.

It may seem redundant to enact laws where an industry standard is already working well, but I understand the lawmakers’ perspective. You can’t just leave everything to market forces. Yes, right now it seems PCI is on the right track to provide protection for consumers. But this may not necessarily be the case in the future. Call it short term overkill, long-term insurance.

In the meantime, the retailers are trying to play “pass the hot potato” with the credit card issuers. While I agree that less data storage is less potential for data theft, there are accounting issues and simple business streamlining issues that need to be addressed. Guess what? The retailers’ gambit is not going to work. PCI DSS is not reversible, it’s only going forward. Credit card companies provide a valuable service to both consumers and retailers, and in this game, they have the power. Don’t like the requirements VISA is imposing? You have a choice - either comply, or don’t accept VISA anymore (and good luck with that…!), or outsource CC processing entirely.

The reality is that PCI is going to become part of the cost of doing business. It’s several years too late, but better late than never.

You know that data breaches have become part of big business reality when the Harvard Business Review publishes a hypothetical case study entitled “Boss, I Think Someone Stole Our Customer Data”. The case study does a very good job of illustrating the initial confusion and many gray areas that enterprises face when confronted with a possible breach.

When the first signs of a possible breach are raised, often there would be some uncertainty regarding the nature of the breach, its extent and whether there has been a breach at all. Insider breaches are especially tough, because insiders have a better shot at covering their tracks than intruders from the outside, and have more visible attack surfaces to begin with (this is one place where database monitoring can help).

Once it is established that a breach had occurred - and this does not have to be with 100% certainty, it’s enough to establish that a breach is likely - there are many things an enterprise needs to do, and do quickly.

Finding the culprit(s) (the “who done it”) would be many people’s instinct, but actually this should be quite low on anyone’s list, and usually takes a long time to do anyway. The top 3 immediate steps that I would take are as follows:

(more…)

I promised to blog a bit about my traveling, so here I go:

I was visiting customers in India and the US and giving presentations to Oracle user groups in the US. Amazingly, the state of US airports is just getting worse every month. Flying from Israel to India and from India to NY went without any problems. However not did a 35 minute flight from NY to Boston take 3 hours, but they managed to lose my suitcase in the process. Every flight I had in the US in the previous week was late.

Enough moaning and back to Oracle security… I would like to share with you some insights I had while giving presentations. First, it looks as if database security is getting more and more attention from both DBAs as well as IT managers. By show of hands at the presentations, I could see that at least some of the DBAs are handling security issues as part of their day-to-day job. But still, DBAs are not hearing the following from their managers - “last year you met your MBOs because no database breach had occurred. Here is your bonus…” - though many have heard the bonus speech for HA or performance MBO achievements.

Second, almost no one had deployed the July 2007 Critical Patch Update from Oracle. From a crowd of about 50, only 2 raised their hands.

Third and most startling of all, only about a third of the DBAs have ever deployed an Oracle CPU. Let me repeat that again - more than two thirds of DBAs in this small but significant sample have never deployed an Oracle CPU. Ever.

So this got me thinking - do we care about Oracle CPUs at all? Oracle was getting a lot of heat from security researchers for not providing security patches or providing them with irregular intervals. Finally, Oracle is stepping up to the plate with the patches. They provide them on regular basis, they announce the the patch before issuing it so organizations can prepare for them. They are improving coding techniques and code vulnerability scanning tools. And after all that, customers are still not protected. The reason for this is that the database is an extremely complicated piece of software and is the life-line of the organization. An enterprise will need to test the CPU thoroughly before deploying and testing takes a lot of time (months). This is further complicated by the fact that many organizations have applications running on top of Oracle databases, and those applications are not “forward compatible” and certified by their vendors to run on future Oracle versions.

Ironically, from a security standpoint the situation after a CPU is announced is actually worse than before it is announced: The hackers get a road-map of all the vulnerabilities while most organizations have not yet plugged those holes. This is a similar notion to hacking IPS software in order to retrieve vulnerabilities (see this black hat presentation).

I’m not saying that Oracle should stop providing CPUs. Quite the contrary, I’m saying that organizations must deploy CPUs as quickly as possible to keep this sensitive period short. Even considering the objective difficulties in applying patches, it seems that enterprises are not taking database vulnerability seriously enough. Also, organizations must have other solutions to mitigate the threat in post-CPU release period. Those solutions must not change the Oracle software at all or else they will fall into the same trap of interdependency, stability issues and so forth. They must provide virtual patches to externally test for attacks and plug the security holes from the outside.

I am curious to know other people’s experiences and views on this topic - so fire away…

Recent opinions about PCI-DSS and whether it should or should not be softened made me think of a wider issue I often come across: The illusory equivalence of regulatory compliance with “security”.

I would therefore like to try and argue that compliance cannot equate security, and it never will. The reasons for this are inherent to the motivation behind regulations and the process by which they are created and enforced.

First, regulations (be they law or industry standard) have limited scope. They are there to ensure that a certain set of rules is followed in order to achieve a specific goal. If they end up generating better security against threats outside their target scope, that’s a positive side-effect. Sarbanes-Oxley (SOX) is there to ensure truthful financial reporting to the SEC, so it requires financial data to be watched closely. If millions of customer records are stolen from a public company, under SOX this company may be 100% compliant as long as they can show how it affected its financial figures, but a company that allows massive data theft to happen is clearly not as secure as it ought to be.

Additionally, regulations are often created, even within their applied scope, as a minimum requirement. That is, a requirement that many organizations within the relevant space have some chance of fulfilling - perhaps not the lowest common denominator, but a low one to be sure. Some regulations emphasize auditing, focusing on what had already happened, and not necessarily preventing it from happening in the first place. In other words, regulatory compliance is not an Olympic medal - it just means you get to participate in the opening ceremony.

Third, enforcement of compliance is not perfect. In some cases (HIPAA comes to mind) it’s very weak. This leaves many companies not even knowing whether they’re compliant or not - it is up to their own interpretation, which usually means the path of least resistance. With full compliance setting the minimum standard, less than that is, well, not much…

And fourth, regulations are often too slow to keep up with emerging threats. A few years back nobody knew what phishing was, or how to gain DBA privileges using SQL injections. Regulatory requirements, especially legislation (like SOX, HIPAA and GLBA) are difficult to update, and so will always trail behind fast moving computer-related threats and techniques. PCI-DSS stands a better chance, since it is an industry standard and was originally intended to be updated as circumstances change.

While some enterprises struggle with achieving compliance, leading companies will have systems and procedures in place that exceed the compliance requirements. Their focus will be on securing their systems and data, while achieving compliance with minimal extra effort and at minimum cost.