c o m m e n t ALL SECURE
BY MARY ANN DAVIDSON
On the Security Evaluation Evolution
Looking at the past, present, and future of security evaluations
’m about to have a significant anni-
versary with Oracle: my 20th. When
I look back, it does not seem pos-
sible 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 have 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. O
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.
nextSTEPS
LEARN more about
Oracle Security Evaluations
otn.oracle.com/deploy/security/seceval/security-
evaluations.html
application security and compliance
oracle.com/security/software-security-assurance.html
READ more Davidson
blogs.oracle.com/maryanndavidson
