As Oracle Corp. grapples with its patch quality and speed, some in the security community have compared it unfavorably to Microsoft Corp. Oracle security execs say this is an apples-to-oranges comparison, given the vast differences between patching the complex server software Oracle produces and the client technologies that makes up much of Microsofts security focus.
Still, Microsoft has managed to turn around its reputation as a large bug target with poor attention to secure code, in part by pulling together a centralized security organization, MSRC (Microsoft Security Response Center).
In contrast, Oracle has chosen to route security issues back to the appropriate product group and developer in an effort to create an ownership mentality toward code flaws.
While some charge that Oracle thereby puts the fox in charge of the hen house by giving developers too much say in whether their own code is buggy, Oracle views it as part and parcel of an educational effort that reaches anybody and everybody whose fingers are in the product pie.
eWEEK News Editor/Operations Lisa Vaas had a chance to chat with Oracle Chief Security Officer Mary Ann Davidson about this and other security matters while on a trip to the heart of Oracles security setup in Redwood Shores.
Could you explain why a decentralized security approach makes sense for Oracle?
Theres a couple of practical reasons. The reason we have a security bug fixing team is not to fix the issues. Its to be an analytical process. (Its to analyze things like) "How do we have processes and systems to track issues? How do we make sure were prioritizing them so the worst ones are fixed first?"
How does this work on a practical level?
We have a group in the database team called DDR (Diagnostic and Defect Resolution). Normally they do a log of regular bug fixes. If a fault is reported, it gets processed and tracked by the group whose job it is to fix bugs.
Thats a centralized approach, though. When and why did you move the bugs back to the developers?
We did security bugs that way awhile, but eventually decided to move it back to developers who did the code for a few reasons.
The main one is you want people to make fewer mistakes. One way to do that is make sure they know what they did wrong the first time.
The second reason is accountability. You want to foster the idea that you need to understand how this defect got in there, how it was exploited. You want to see how a hacker got in there and how it was exploited.
Do you think this type of security structure will work better with Oracles growth-via-acquisition?
A small team will never scale. A lot of companies talk about having a culture of security. Thats the main thing you need, otherwise youll never have enough of people that you need.
Some things must make sense to centralize, though. Im thinking of encryption and such.
Policies, training, those things make sense to centralize. Instead of every developer having to run all the pages of secure coding themselves, we developed a Web-based training class we rolled out against the product stack. All you have to do is fire up your browser and take the class.
Similarly, when we make acquisitions, one thing we do is talk to the security weenies from the acquired companies. We say, Theres stuff we do to engineer security into our products, but youre probably doing some of the same things.
If youre doing something, if youve got something in your bag of tracks, we say, "Hey, lets incorporate that, so we dont have one PeopleSoft security way, and one JD Edwards security way, and one Siebel security way."
Does that mean s we might be in different phases of doing stuff across the company? Yes, but we have one goal, not this guy doing it his way and some gal doing it her way.
Other things to make centralized are the technical aspects of security knowledge like encryption. So we have, as part of our cooking standards, are you using Oracle licensed encryption routing? Weve already licensed, vetted, and probably have fixed (whatever theyd have applied it to).