COMMENT: All Secure
Keeping Current with StandardsBy Mary Ann Davidson
Oracle expertise in secure development practice is certified.
There is a quote attributed to Andrew Tanenbaum that goes, “The nice thing about standards is that there are so many of them to choose from.” In truth, open, transparently developed software standards are important, especially with our increased reliance on and the interdependency of complex systems. Let’s face it, the internet wouldn’t work if we couldn’t agree—via standards—on how to route messages, map arcane IP addresses to things people understand, and so on. A number of security standards have also emerged in the past several years as people have tried to integrate the security of disparate components (à la SOAs) or enable security attributes and assertions to span organizations.
Oracle also embraces standards, many of them internal standards related to secure development practices. These standards are incorporated into a document known as the Secure Coding Standards (SCS), which my team authored, revised, and maintains. SCS is the foundation of almost everything we do in security—our secure coding training is based on it.
Maintaining SCS is a big project and falls smack into the category of projects that are not “urgent” but are very important. Recently, we’ve taken SCS from a PDF document to a wiki-ized document that is easier to use, better organized, and richer, and SCS is the most referenced section of my team’s wiki. For example, we know that telling developers, “Don’t do X,” is less effective than telling them, “Do Y instead.” Thus, we continue to add “case law” illustrating the right way—or several right ways—to address security problems developers run into (such as how to handle passwords on the command line).
Specific additions we are making to SCS include
New hacks. There are new classes of attacks being discovered all the time, some of them by the Oracle ethical hacking team. We are documenting the new attacks: how they work and how developers can avoid the vulnerabilities that lead to the attacks.
Tool usage. We continue to develop automated tools in-house (and to license third-party tools) that help us find security vulnerabilities in our code. We are reviewing the in-house tools to ensure that they are robust enough to mandate via the SCS. Furthermore, one of our goals as we maintain the SCS is to develop concise coding-practice rules and to try to incorporate them into the automated tools we use. Automation helps people do the right thing—and avoid the wrong thing—more easily.
Another way in which Oracle embraces standards is in our expertise as security professionals. For years, there has been a plethora of certifications for security practitioners, such as Certified Information Systems Security Professional, Certified Information Security Manager, Certified Information Systems Auditor, and so on. While most certifications to date have focused on operational information security practice, a new certification has been developed that focuses on secure development practice: the Certified Secure Software Lifecycle Professional (CSSLP). To my knowledge, CSSLP is the first (and only) certification focused on those who design, build, and deliver secure software. And frankly, certifying those who secure operational systems without certifying those who build security into them is like certifying architects without certifying structural engineers.
I am pleased to say that most of my team—Oracle Global Product Security—has both applied for and received the new CSSLP certification (myself included). While it is too early to tell if CSSLP will catch on, I thought it was important for Oracle to show our commitment to secure development practice by having the people whose full-time jobs are focused on “secure software lifecycle” receive such certification. In my opinion, what is notable about so many of us receiving CSSLP certifications isn’t the piece of paper from the International Information Systems Security Certification Consortium, the issuing body that’s known as (ISC)2. Instead, it is the collective years of experience these CSSLP certificates represent in Oracle secure development practice. Most of my team has been in security—and in fact, in security at Oracle—for years and years. I’ve known some of my team members since I joined the Oracle Secure Systems group in 1994. They are still at Oracle and still working in security. It’s a richness of experience that the CSSLP merely acknowledges but does not confer. Still, I’m proud that (ISC)2 has recognized what I’ve known all along: Oracle has a wealth of expertise in secure development practice.
Mary Ann Davidson is the chief security officer of Oracle, responsible for secure development practices and security evaluations and assessments. She represents Oracle on the board of directors of the Information Technology Information Security Analysis Center (IT-ISAC), has served on the U.S. Defense Science Board, and is on the editorial review board of SC Magazine.