Podcast with Application Security: Databases in the Crosshairs - Twenty-Four Seven Security

« Many Companies Will Fail PCI Deadline | Main | Who Is Going to Secure Virtualization? »

September 29, 2007
Podcast with Application Security: Databases in the Crosshairs

Listen to or download the 7:08 minute podcast below:

What follows is the transcript of my podcast with Ted Julian, Vice President of Marketing for Application Security, Inc., where we discuss the problems and best practices of database protection, how Pfizer could have avoided their third high-profile data breach in three months, what companies need to know about PCI compliance, and finally, the future of database security.

What are some of the problems and best practices companies need to know about when protecting their database?

It certainly starts with, "where are they?" Even with some of the largest, most tightly run organizations in the world, when we go and do a discovery, they almost always find some databases they don't know about, you know, whether it's because things are fairly organic and people are throwing up new applications or maybe they've bought three regional banks in the last quarter and they're still trying to figure all that out. It's not unusual at all to find even dozens of substantial databases than an audit or a security or other group didn't even know were there.

I see on the Application Security website that you say you're the industry's only complete database security solution. What does your solution have that others don't?

Essentially, what our DbProtect suite allows customers to do is apply the same security best practices that they've deployed over the past, almost 10 years, on their network and their general-purpose hosts, and bring that to their database. So specifically, I mean, not only discovery, which we talked about just a second ago, but also having done a discovery, the ability to assess those discovered systems for security vulnerabilities, misconfigurations that can allow people to abuse their privileges or otherwise compromise the database. Those two things are kind of the first leg on the stool.

The second is activity monitoring on the database. So that even if, for example, the DBA tries to do a select star against the credit card column -- take all the credit card numbers in the database, they'd probably have all the privileges in the world to do so but with good activity monitoring, you could flag that. And then finally the third, sort of optional component of our suite is column level encryption on the database so that even more the DBA tried to take just a few of the credit cards, something that even a finely tuned monitoring system might not notice, they go to grab them and they can't get them because they're encrypted and they don't have the key so in short, it's the ability to provide discover, assessment, and monitoring across the enterprise for those database. Everybody else that's in the "database security" business has one leg on the stool, no one else has even two, let alone three.

Anybody following the news probably knows that Pfizer just had its third data breach in three months. How would Application Security help Pfizer prevent these data breaches?

That reflects on everything we just talked about. I mean it could be as simple as the breach happens because it was one of those unknown databases and because it wasn't being tracked by anybody, so it still had default IDs and passwords in place on a privileged account and that's how somebody was able to get in. That's a simple problem to fix that we would easily discover.

It could be that somebody tried to run a known vulnerability against the database and get privileged on it and then stole the data. Well, that's something that good activity monitoring would alert you in real time against something like that. Or, you know, it could be that sophisticated DBA who might get through some of those other hoops but with column level encryption, they'd go to take the goods, customer data, whatever it is, and then it's useless to them because it's encrypted. So, there's any number of ways that we can help.

I think the key thing is that with these attacks these days, especially as compared with maybe two, certainly five years ago, they're focused, they're after data that they can sell. They're not looking to just deface a web site or otherwise create downtime so much, they want to harvest a large amount of data and to do so ideally without being caught, without tipping off any alarms, so they can then sell that data and with that change in threat, databases just come out as a real obvious target since after all, a lot of people in the IT organization labor mightily to make those things highly available with the most up-to-date information as possible.

What do companies need to know about PCI compliance and how can Application Security help them achieve this?

Anybody who's looked at PCI has probably heard about the "dirty dozen", where there's a dozen high level requirements within it. The short answer is that we help companies ground that PCI compliance effort or really any compliance effort in the database where that data tends to exist. So, you'll see when you tease through the requirements in PCI that in addition to maintaining, you know, up-to-date anti-virus and all the rest, they've expanded over time to include keeping your databases patched because that is where card-holder data sits so those systems need to be secure.

There's also a requirement in there to encrypt cardholder data and so we certainly apply there as well. And then the last thing, then, very important one to point out is the notion of compensating controls in PCI. In theory, the notion of compensating control, a substitute if you will, for some other requirement can apply to anything within PCI. However, where we most often see it applied is on that encryption requirement because of any number of reasons. It could be because...A) You simply can't encrypt it. With some older obscure database there simply isn't an encryption solution available. Or, it could be because of the nature of your environment, if you tried to deploy encryption, you know, the performance impact would be so severe the system would crash or you wouldn't be able to process transactions.

Anyway, there are any number of barriers to that particular requirement. Well, because of compensating controls, you might, for example, go to your auditor and say, "What we'd like to do as a compensating control is deploy granular monitoring against that database so that, you know, somebody could try to steal the data but we'd either be able to stop them or worse case, know about it immediately and be able to shut it down before the data could be leveraged against the customer." So that is a fairly common example of a compensating control. Monitoring, as a compensating control, against the encryption requirement since it is the one that many companies struggle with more than any other.

What do you see as the future of data security, basically both in terms of the coming attacks and the protection that's going to be needed to defend against them.

The bad guys are following the money, that's why databases are in the cross-hairs. You see it in the breaches that are happening, you see it in the research. Oracle, for example, was forced to move to a quarterly patch update schedule because there are so many Oracle vulnerabilities being discovered that they average about 80 or so new vulnerabilities every quarter and, I think, the hackers will continue to follow the money and to me that means continuing to move up the IP (internet protocol) stack into the applications themselves.

So, I think when we look forward we will see attackers looking at critical systems like SAP and PeopleSoft, Oracle Financials, other things that are the backbone of a company's business because that's the most valuable data a company has and thus what attackers are going to go after.