Hello. My name is Duncan Harris. I manage Oracle's Security Assurance Group which includes our product security vulnerability handling group (SecAlert) under Darius Wiles, our internal ethical hackers and our security evaluations team. The group's job is to introduce and encourage security improvements in the way our product development organisations build new and maintain existing products. Notably, that means we're less concerned about the impressive new security features and functions built into Oracle products so much as we are about how those features and functions are built. So, while we look at pre-release and new security product options like Database Vault, at security features like Virtual Private Database (VPD), and at building block security functions like the database's privilege and role model, we are just as interested in non-security features and functions and how securely they have been built. The vast majority of our product security vulnerabilities are found in code that is nothing to do with security features and functions, so we need to be sure that all our developers know how to identify and avoid insecure coding practices. It is an ongoing effort!
You may have seen the recent press release about the completion of our Common Criteria EAL4+ security evaluation of Oracle Application Server. There's lots of detailed information at http://www.oracle.com/technology/deploy/security/seceval/index.html and http://www.oracle.com/security/security-evaluations.html, but I thought I would try to explain a little about what Common Criteria security evaluations really mean - what they are and what they are not.
Common Criteria is the short name for the formal international standard ISO 15408. It's a rather dull 800+ page read, and is recommended if you're having trouble sleeping, but the main thing to know about it is that it's effectively a very large dictionary and grammar of IT security terminology. So, if you want to say something about IT security correctly, Common Criteria (CC) states in formal terms exactly how you must say it - it's a sort of etiquette guide for IT security. In simple terms and correctly used, Common Criteria allows IT purchasers to specify what security functions they're looking for in a product or a system and how thoroughly they want to be sure those functions work. It also allows IT product developers and system integrators to specify what security functions they're offering in a product or system and how thoroughly they have checked that those functions work. Sometimes a purchaser's and developer's formal CC specifications match and a financial transaction then takes place, though often it's vice versa! Some purchasers, mainly those that deal with their country's defence or intelligence services, are mandated to buy CC evaluated products by law or by national security policy. The process of matching a purchaser's formal CC specification, called a Protection Profile, and a developer's formal CC specification, called a Security Target, is a CC security evaluation. An independent third party, usually a formally licensed technical laboratory of CC evaluators that follows the formal CC Evaluation Methodology, conducts the security evaluation. A CC certifier or validator, who usually works for the part of government that runs the national CC evaluation scheme, oversees the evaluators� work. There are now 24 countries that recognise each other's CC certificates issued for products that have been evaluated. There is much more information about these formal processes and arrangements at http://www.commoncriteriaportal.org.
Obtaining a CC certificate for a product for the first time can be a lengthy and costly exercise but it is considered by most product developers to be a worthwhile exercise either, cynically, because it opens the door to those markets mandated to buy CC evaluated products, or, virtuously, because it shows to all security conscious customers that the product's security functions were built with care. And, crucially, the independence of CC evaluators and the national CC scheme mean that purchasers aren't just taking the product developer's word for the correct working of the product's security functions.
So, what does a Common Criteria certificate for a product really mean? In my experience, about one third of the assurance work done by CC evaluators validates that the product developer follows good physical, personnel and procedural security practices, e.g., that we have security guards, door locks, and ID badges; that we do background checks on staff before employment; that we use a configuration management system to store and maintain our source code and that we test our product. None of these checks are anything directly to do with the product being evaluated, but are a strong indication that the developer has a secure environment in which to build a product. For many of our customers that care most about our CC evaluations, this is as important as the product's security functions themselves because it helps alleviate their concerns about backdoors, undocumented commands, trojans, etc. being introduced by a malicious employee or moles conducting industrial or state espionage. This aspect of CC evaluations is critical because Oracle's continued support of security evaluations for the 12 years since we received our first certificate in 1994 shows to the most security conscious customers in the world that Oracle is a company that understands their concerns are not just strictly about the products we sell, but also about the surrounding assurance processes. There are very, very few other IT product vendors that seem to have recognised this intangible and backed it with years of commitment.
The other two thirds of a CC evaluation are related to the product under evaluation itself, for example, the validation that the product's security functions were built in early on at the architectural design stage and that that high level security design was correctly carried through to low level functional and design specifications and into source code and tests. While this aspect of the evaluation is also very critical (as it attempts to prove that those security functions were built correctly), it is somewhat mechanical. What is more interesting from my standpoint is that to truly focus in on the correct working of those security functions, certain restrictions are imposed through various assumptions about the product's (secure) configuration (lock down) and the security of the environment in which the product operates. These assumptions are what lies at the heart of any controversy you may have read about CC.
Oracle is not alone in assuming that its products' security functions should be tested by CC evaluators in a benign network environment where, for example, all calls to API functions are required to be "correctly formed" thus excluding any buffer overflow, SQL injection and similar attacks. Why do we choose such unrealistic environments? Because we can (get away with it)? No. Because we want to get the CC certificate as quickly and cheaply as possible? No. We do this because it is the best way for evaluators to confirm that the security functions are working correctly and cannot be bypassed in the sort of environment that our security-conscious customers normally face. Customers care that products may suffer from nasty vulnerabilities such as the ones that can result in a denial of service. However, failure of a core security mechanism that is used in day-to-day operation of their normal systems is more worrying because customers are relying on these controls to limit the actions of authorised staff as well as prevent potential abuse by attackers. If a product's basic discretionary access control (DAC) operates correctly for 99.9 % of operations, but doesn't when users with certain privileges try a command for which they don't have the correct privilege, there is a breach of a core security policy. In other words, failure of the core security functions that CC evaluations examine is more serious in security terms because such failure undermines a customer�s entire security strategy.
It is perfectly possible to modify the typical CC environmental limitation to assume a hostile network environment and make the CC evaluators consider the sorts of attack methods that our ethical hacking team and security researchers adopt. To date, however, we believe it is better to leave those attacks to those that practice them regularly without the formal rules that CC imposes. That is not an admission that CC fails to cope with modern networked environments. As I mentioned at the start, CC is a language and those who criticise CC don't really understand how powerful and flexible it is. Since CC is a language, it is always evolving to reflect current security concerns, changes in computing capabilities, new product technologies and new attack potential. The critics probably should be criticising the way CC as a language is abused, in the same way as those who write incomprehensible or ungrammatical English can be fairly criticised (as my staff know all too well!) This may seem like a subtle point but in fact CC, correctly used, can fully address the criticisms levelled at it. It's simply that to do so, because of the CC's formality, it is likely to take a lot more effort than the critics are prepared to take.
So, while typical Common Criteria use has its faults, they are not as fundamental as its critics would have you believe. Indeed, Oracle sees great advantage in working with the CC community, for example through the CC Vendors� Forum that works with the CC international institutions to improve CC and address the common criticisms. We have also recently worked with NSA and other database vendors to make sure that NSA�s standard Database Management System security requirements, specified in a CC protection profile, were realistic and achievable. Common Criteria has been a very strong influence on our internal Secure Coding Standards, a document that drives almost everything that my group does. While security evaluations are the oldest foundation of Oracle Software Security Assurance - http://www.oracle.com/security/software-security-assurance.html - even today they continue to challenge our development teams as we put more and more products through the rigour of Common Criteria.
