Is Oracle throwing in the patching towel?

Alex Rothacker, director of security research for Application Security’s TeamSHATTER, says Oracle is ignoring far too many security vulnerabilities.

Tim Whitman, Application Security’s PR man, sent me some of Rothacker’s thoughts in an email yesterday:

It appears as if Oracle has thrown in the towel on fixing database vulnerabilities. Assuming the January 2012 CPU report stays the same as the Preview, they will have set a new record low of just TWO database fixes (MySQL not included — it should be noted that this is the first time that MySQL was included in the CPU).

The previous record was set in the last CPU in October with just five fixes. Prior to that, there were three different CPUs that had just six fixes. It appears that the drop-off began in 2010, when they started consistently having single-digit fixes, other than July 2011 when there were 16 (incidentally, TeamSHATTER was credited with 11 of those findings).

It should be noted, too, that Application Security Inc.’s research arm, TeamSHATTER, has discovered and disclosed multiple vulnerabilities to Oracle that are currently in the queue, but it appears they didn’t fix any this time around. And the prevailing thought from our researchers is that several of those submitted are high risk and should have been fixed.

At a minimum, this disturbing trend begs the question as to why there is such a significant drop-off and what this means for Oracle customers. And perhaps even more disturbing is that this is occurring when database attacks are at an all-time high.

Oracle has been criticized many, many times over the years for sitting on vulnerabilities for months and even years, so this kind of criticism doesn’t surprise me.

There’s a lot about the patching process that we don’t know about. Some fixes take longer to develop than others, and unless you work in Oracle’s patching department, everything is a guessing game.

Microsoft has also gotten a lot of criticism over the years for not patching the latest big zero-day flaw in time for the first Patch Tuesday update to follow the reports.

Whenever I’ve seen someone criticizing Oracle’s process, I’ve reached out to the database giant for its perspective. I’m always greeted with a PR wall. The most I get is an emailed statement about how seriously Oracle takes security.

That being the case, I’m not going to bother with the PR machine this time. I know it will prove fruitless.

It’s a shame too, because I’ve known Oracle CSO Mary Ann Davidson for a long time and she’s one of the smartest people I know. Listen to her for a few minutes and you know that security is something she is deadly serious about.

But the PR wall never lets her out unless it’s for a general Q&A in which they tell you ahead of time what we can’t talk about.

It’s a problem because when researchers criticize Oracle and the company doesn’t give an adequate response, it adds to the perception that it doesn’t care about security holes or the customers it puts at risk.

In the interest of fairness, allow me to dig up some comments Davidson made about the company’s security process at SOURCE Boston 2010, when she was a keynote speaker. It doesn’t address Rothacker’s concerns, but it does present a picture of what Davidson and her team do to minimize security holes.

Oracle has had its share of criticism this past decade over coding holes that led to many a critical patch update. As a result, CSO Mary Ann Davidson has worked to change her company’s code-writing culture.

How well that’s gone is in the eye of the beholder (customer). But at the SOURCE Boston conference Thursday, Davidson walked attendees through the specific things Oracle has done to make security a priority from the start of the product development process.

She acknowledged that customers have come down hard on Oracle to do better in recent years, especially in the aftermath of acquisitions like that of Sun Microsystems, which Davidson described as a boa constrictor swallowing an elephant.

“Flaws can limit accountability, make it easier for someone to corrupt systems internally and falsify measurement and reporting,” she said. “It’s bad if there’s a defect in your software. It’s worse if a customer gets breached while you are hosting a service for them.”

She noted that a growing number of customers want third-party organizations to look at Oracle’s code. They want to know exactly what Oracle is doing for security, she said, adding that as business becomes more regulated, the burden on the vendor as a supplier is heavier than ever. As Oracle acquires more technology, that pressure has been amplified.

When a team was identified as struggling. “We said, ‘you need to get with the program. This is your cure plan.’ This product needs to be brought into alignment.” The leader of that team resisted and thought it was unimportant, she said. As a result, that person felt the full heat of upper management.

So what does Oracle’s coding process look like these days? Davidson painted the following picture:

When vulnerabilities are discovered, it falls to the original product developers to fix it. The idea isn’t to punish them, but to help them understand the impact of their actions so they can learn from it, she said, adding, “They need to understand how it broke.”

Though not punitive, it has been a powerful motivator since no one wants to go back and fix something because it wasn’t done right the first time.

Each product group has to work through a security checklist before something is released. There are different checklists for different groups.

Security assurance policies are hammered out at the C-level, and vulnerability handling policies are developed by the chief corporate architect and CSO (her).

A security oversight committee reviews business risk and security, compliance, and physical security. It meets twice a year.

“Each development organization has a security lead,” she said. “There are security points of contact within each product component.”

There’s a security steering committee and assurance steering committee.

And there’s security training that everyone must have. Those who drag their feet are shamed into taking care of it.

“Nothing shows a company how it’s doing with security training attendance like a bar chart comparing how you’re doing compared to competitors,” Davidson said. “Our training numbers went up when some managers saw the charts. I don’t assume malice or incompetence if there are other explanations. The goal isn’t to just beat people up. It’s not about putting someone on report.”

One thing I’ve learned after eight years of covering security: When two sides fight it out over a specific point of view, the truth is usually somewhere in between.

–Bill Brenner

one-stop view of latest business threats. We created it for you! Bookmark it! Use it!

CSO’s Daily Dashboard gives you a