COMMENT: All Secure
On the Security Evaluation EvolutionBy Mary Ann Davidson
Looking at the past, present, and future of security evaluations
I’m about to have a significant anniversary with Oracle: my 20th. When I look back, it does not seem possible that 20 years have gone by. On the other hand, when I think about how many products I’ve worked on and how many product release cycles, it’s hard to believe it has been only 20 years.
Most of my career at Oracle has been in security. I joined Oracle Secure Systems in 1994, when we were just finishing the first third-party security evaluations we had ever done. It was a point of pride that Oracle was the first (and only) vendor to do a “double double”: evaluations of Oracle7 and Trusted Oracle7 against both the U.S. Trusted Computer System Evaluation Criteria (TCSEC, or “Orange Book”) and the European Information Technology Security Evaluation Criteria (ITSEC). Years later Oracle is creeping toward 30 security evaluations, and my team is still responsible for them—and a whole lot more. When I look back, I realize that the roots of everything we do in Oracle Software Security Assurance were planted and watered through security evaluations. It seems fitting that I discuss them on my 20th anniversary.
Let’s face it: everybody who sells a product says it is secure, because there isn’t much of a market for products “so easy to break in to, your grandmother can do it!” Unless customers can afford to hire a team of security experts to tire-kick every product they have, it’s helpful to have an independent third party vet the security of the product. That’s where security evaluations come in: an independent third-party lab (government-certified to do the work) validates a product against a standard of what you mean when you say you are secure. An evaluation considers what kind of threats a product needs to meet, the security means by which the product meets those threats, and how well the product lives up to the security claims. Evaluations can be done to lower or higher levels of assurance: generally, the higher the assurance level, the more work the evaluators do to satisfy themselves that the product is as secure as advertised.
Long term, evaluations generally improve development processes, because so much of what evaluators do involves how a vendor built a product, to ensure that security is designed into the product and not bolted on in the last two weeks of development. In addition to building the actual security functionality, Oracle has changed its development processes to support security evaluations, and the company has been improving its software assurance ever since.
What’s changed in evaluations? For one thing, there is now an ISO standard (15408, Common Criteria) for doing them. With the “mutual recognition” provisions, a vendor can do one evaluation—up to Evaluation Assurance Level (EAL) 4—that “counts” in multiple countries. The days when each country had its own method for security tire-kicking were expensive, wasteful, and duplicative—and the time, people, and money you invested in validating exactly the same product 20 ways to Sunday could have been better spent making products more secure for everyone.
Oracle has also expanded the breadth and depth of evaluations: when we add major new features, we expand the scope of evaluations—even of products we’ve evaluated many times, such as Oracle Database. We evaluate more products now too, including Oracle Application Server and Oracle Identity and Access Management. Sometimes we “add evaluations” when companies we acquire have products going through them.
Another positive development is the realization that evaluations need to evolve too. Everybody and his kid hacker now has a take on how to improve software assurance. Some of them are even good ideas. The one thing that hasn’t changed is that doing one thing that counts everywhere will lead to better security than having everyone or every country tire-kick security slightly differently. You won’t get better plumbing in your house if every room has a different building inspector.
We do formal security evaluations so that customers have independent attestation of how secure our products are. But we consider security evaluations just the starting point for assurance. Whether it is working to make our own assurance measures better or to improve existing evaluation programs—such as Common Criteria—we want to raise the industry assurance bar. If only one house on the block is built for a 100-year flood, it doesn’t do the community any good if that once-in-a-hundred-years flood happens today.
Mary Ann Davidson is the chief security officer of Oracle, responsible for secure development practices, security evaluations, and assessments. She represents Oracle on the board of directors of the Information Technology Information Security Analysis Center (IT-ISAC), is on the editorial review board of SC Magazine, and has served on the U.S. Defense Science Board.