Corporate Security Blog

Welcome to Oracle’s corporate security blog

Mary Ann Davidson
Chief Security Officer, Oracle

Hi, all! My name is Mary Ann Davidson and I am the Chief Security Officer for Oracle. I’m the first contributor to our relaunched corporate security blog. Having many different security voices contribute to this blog will help our customers understand the breadth of security at Oracle - across multiple organizations and multiple lines of business. Security at Oracle is way too big (and too important) to be constrained to one person or even one organization. This blog entry will describe how security is organized at Oracle and what my organization does specifically.

When I joined Oracle (and before I started working in security), we were just beginning to build “Oracle Financials” – at the time, general ledger, purchasing and payables applications - which have long since expanded to a huge portfolio of business applications. Since then, we’ve continued to grow: more business applications, middleware, operating systems, engineered systems, industry solutions (e.g., construction, retail, hospitality, financial services) and of course, many clouds (infrastructure as a service (IaaS), platform as a service (PaaS) and Software as a Service (SaaS) - business applications we run for our customers). Plus databases, of course!

The amount of diversity we have in terms of our product and service portfolio has a significant impact from a security perspective. The first one is pretty obvious: nobody can be an expert on absolutely everything in security (and even if one person were an expert on everything, there isn’t enough time for one person to be responsible for securing absolutely everything, everywhere in Oracle). The second is also obvious: security must be a cultural value, because you can never hire enough security experts to look over the shoulders of everyone else to make sure they are doing whatever they do securely. As a result, Oracle has adopted a decentralized security model, albeit with corporate security oversight: “trust, but verify.”

With regard to our core business, security expertise remains in development. By that I mean that development organizations are responsible for the security-worthiness of what they design and build, and in particular, security has to be “built in, not bolted on” since security doesn’t work well (if at all) as an afterthought. (As I used to say when I worked in construction management in the US Navy, “You can’t add rebar after the concrete has set.”)

Security oversight falls under the following main groups at Oracle: Global Physical Security (facility security, investigations, executive protection, etc.), Global Information Security (the “what” we do as a company in terms of corporate security policies, including compliance, forensic investigations, etc.), Corporate Security Architecture (review and approval prior to systems going live to ensure they are securely architected), and Global Product Security, which is my team.

I mentioned I am the CSO for Oracle but really, that would be better categorized as “Chief Security Assurance Officer.” What does assurance at Oracle encompass? In essence, that everything we build – hardware and software products, services, and consulting engagements – has security built in and maintains a lifecycle of security. In order to do that, my team has developed an extensive program – from “what” we do to “how” we do it – including verifying that “we did what we are supposed to do.” The “what” includes secure coding and secure development standards, covering not only “don’t do X,” but “here’s how to do Y.” We train many people in development organizations on these standards (e.g., not only developers but quality assurance (QA) people and doc writers, some of whom write code samples that we obviously want to reflect secure coding practice). We have more extensive, tailored training tracks, as well. Our secure development requirements also include architectural risk analysis (ARA), since people building systems (or even features within systems) need to think about the type of threats the system will be subjected to and design with those threats in mind.  These programs and activities are collectively known as Oracle Software Security Assurance (OSSA).

One of the ways we decentralize security is by identifying and appointing people in development and consulting organizations to be our “security boots on the ground.” Specifically, we have around 60 senior Security Leads and over 1,700 Security Points Of Contact (SPOCs) that implement Oracle Software Security Assurance programs across a multiplicity of development organizations and consulting.

Development teams are required to use various security analysis and testing tools, including both static and dynamic analysis, to triage the security bugs found and to attempt to fix the worst issues the quickest. We use a lot of different tools to do this, since no one tool works equally well for all types of code. We also build tools in-house to help us find security problems (e.g., a static analysis tool called Parfait, built by Oracle Labs, which we optimize for use within Oracle). Other tools are developed by the ethical hacking team (EHT), e.g., the wonderfully-named SQL*Splat, which fuzzes PL/SQL code.

The EHT’s job is to attempt to break our products and services before “real” bad guys do, and in particular to capture “larger lessons learned” from the results of the EHT’s work, so we can share those observations (e.g., via a new coding standard or an automated tool) across multiple teams in development. I’m also pleased to note that the EHT’s skills are so popular that a number of development groups in Oracle have stood up their own EHTs.

My team also includes people who manage security vulnerabilities: the SecAlert team, who manage the release of our quarterly critical path updates (CPUs), and the Security Alert program, as well as engaging with the security researcher community.

Lastly, we have a team of security evaluators who take selected products and services through international Criteria (ISO-15408) and U.S Federal Information Processing (FIPS)-140 certifications: another way we “trust, but verify.”

Security assurance is not only increasingly important – think of the bazillions of Internet of Things devices as people insist on implanting sensors in absolutely everything - but increasingly asked about by customers who want to know “how did you build – and manage – this product or service?” That is another reason we make sure we can measure what teams across the company are doing or not doing in assurance and help uplift those who need to do better.

In the future, we will be publishing more blog entries to discuss the respective roles of security oversight teams, as well as the security work of operational and development teams. “Many voices” will illustrate the breadth and width of security at Oracle, and how seriously we take it. On a personal note, I look forward to reading about the great work my many valued colleagues at Oracle are doing to continue to make security rock solid, and a core cultural value.