Inside Oracle’s security assurance program

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.”