What's your first line of defense?
- By Patricia Daukantas
- Feb 18, 2004
Mary Ann Davidson, Oracle's security checkpoint
As Oracle Corp.'s chief security officer, Mary Ann Davidson is responsible for product security, corporate infrastructure security and security policies'as well as evaluations, assessments and incident handling.
She represents Oracle on the board of directors of the Information Technology Information Security Analysis Center (IT-ISAC) and is on the editorial review board of Secure Business Quarterly. Davidson has testified about computer security before several House committees, most recently on the value of the Common Criteria certification program.
A 15-year Oracle veteran, she previously served as a commissioned officer in the Navy Civil Engineer Corps, during which she received the Navy Achievement Medal.
Davidson has a bachelor's degree in mechanical engineering from the University of Virginia and a master's in business administration from the University of Pennsylvania's Wharton School.
GCN associate editor Patricia Daukantas interviewed Davidson by telephone. GCN: How would you assess government IT security overall?
DAVIDSON: It's like looking at a class in school. Some students are moving right along and leading the pack, and others might be labeled slower learners.
As an entity, there are things the government is doing well. I believe it is trying to make security more of a purchasing criterion. That not only means the government leads by example, but also that those purchasing decisions can drive the industry.
I've seen a number of vendors who never evaluated their products finally putting them into evaluation because they know the government really means it and isn't going to grant procurement waivers.
The Energy Department seems keenly interested in helping vendors deliver more security out of the box.GCN: From your perspective, what are the top recurring security problems?
DAVIDSON: People still haven't really baked security into their development processes, and until we do that, nothing really will change.
If I don't do a good job of building a product, and there's a problem, I can't say to a customer, 'Well, do you have a firewall or an intrusion detection system? Great! I'm not going to fix my problem.' My customer's not going to accept that. If I didn't get it right, I have to fix it anyway.
On the customer side, you need a security policy in your enterprise. If you don't know what you're protecting and what's at risk, it's hard for you to make the right choices. You don't always need ironclad security on everything, and to figure what's the most important thing, you need a security policy.GCN: What insights did your Navy service give you?
DAVIDSON: I think it's that I can talk the government's language. Granted, I wasn't in the super-secret things in the Defense Department, but I have a tremendous solidarity with that customer base.
I try not to play favorites with any customers. All customers are valuable, and all of them have secrets they want to protect.GCN: How do the Center for Internet Security benchmarks differ from the Common Criteria validation tests?
DAVIDSON: They're very different. The Common Criteria is a set of standards for security evaluations. An independent lab validates product claims to a particular assurance level.
Assurance is the degree of warm fuzziness you feel that the product does what it says it does.
Evaluations are lengthy and fairly expensive. We have 17 of them, which represents about $17 million of investment.
The benchmark is not looking at code or product. It's basically saying: If you have Product X, how do you make sure it's really secure for your use?GCN: If your security benchmark program with the Energy Department succeeds, what comes next?
DAVIDSON: Secure by default is already part of what we do. In the last few product releases, we have hardened more and more things out of the box.
It's a good thing that the government is pushing vendors along the road to more security. The government has such a lot of purchasing power, and it can do a lot of good in the industry by being a demanding consumer, and it should be.
This is why I've been pushing for expanding the scope of requirements for product evaluations'because it helps people build better products. People aren't going to purchase two different versions when one is a secure, high-quality version for the government and the other is a crummy, buggy version for consumers.
Vendors should say: 'We know how to operate it securely. We'll do that, and then when you use it, you don't have to worry about security to a certain extent. We've already made it almost impossible for you to be insecure.' Part of that is the way you build your product, and part is the way it's configured by default.
People have dependencies on certain product behavior. For example, we build a database. We have partners whose applications run on top of that. They may expect the default is to set Parameter A on. If you switch Parameter A to off without telling anybody or testing, all of a sudden everything breaks.
We have an internal rule that we do not change default configurations or parameters between major product releases. In some cases, it can take several years to get rid of certain behavior, because people sort of expect it.GCN: What about Common Criteria validation for Oracle10g?
DAVIDSON: Oracle9i Database Release 2 and Oracle9i Label Security Release 2 both have certificates. We will evaluate a version of 10g. We don't do every single version of every single product because it would be cost-prohibitive. We usually pick whatever the terminal release will be.
Many customers do not pick up the first version, for lots of reasons. The terminal release is going to be out there a long time, and we'll be supporting it, so the certificate will be valid for a long time. At that point the product is typically mature and stable.GCN: What are the strengths and weaknesses of Common Criteria validation?
DAVIDSON: The real strength is that before this, every country had its own criteria. Everybody wanted you to do the same thing slightly differently.
One of the best parts of the Common Criteria program is that it is an International Standards Organization standard, and it provides for mutual recognition. You do an evaluation in any country up to a particular assurance level, and any other country will accept it.
The Common Criteria program works as long as people adhere to the spirit and the benefits it provides. If it goes back to every country and every agency wanting its own special little flavor variant, it's going to fail miserably.
What are the limitations? Evaluations force people to have a good development process, validating claims against particular targets. One of the frequent complaints is that you still have security faults in products that are evaluated.
Evaluations are not hacker tests. They don't scan through all the code to find every possible type of vulnerability. In fact, there are no such tools on the market.GCN: How much of the total IT security picture comes from the database or other applications, and how much is the responsibility of the administrators who choose and manage the operating systems and firewalls?
DAVIDSON: I might have a really good safe. But if I leave my door wide open and someone comes in with a forklift and walks out with the safe, or if I made the combination 1-2-3, I didn't really accomplish what I wanted.
Unfortunately, too many people have a Maginot Line approach to security'and we know how well that worked.
If somebody gets past the front line, what's your next line of defense? If they get past that, what's your next line of defense, and so forth? You can't assume that everybody inside the network is trustworthy and everybody outside is bad. It's more complicated.