Hi I’m Ann Craig and I work in the Security Evaluations Team, part of Global Product Security. My job is to project manage product security evaluations, such as Common Criteria. Today I’m going to talk about the challenges that arise when Oracle submits a newly acquired product for a security evaluation.
Product evaluations under the Common Criteria program involve examining the product, its supporting documentation, and its development environment to establish that product security functionality is acceptable and works as it should. Completion of a Common Criteria security evaluation is an indication of confidence in the security of the product and is recognised by the 26 countries that have signed the Common Criteria Recognition Agreement. At the moment Oracle has security evaluations performed in the UK, Germany and the USA. In a previous blog entry, Duncan Harris provided a good introduction to the Common Criteria. For more details on Common Criteria security evaluations see www.commoncriteriaportal.org.
There is an interesting challenge when a product new to Oracle (such as is the case after an acquisition) needs to be submitted for a Common Criteria evaluation. In such instances, we need to discover what has previously happened regarding the development, functional and test specifications of the submitted product, and gain access to the documentation related to the security functions of the product. Sometimes, this documentation has not been completely brought over to Oracle. In other instances, the documentation simply may not be available. At this point, it may be necessary to rely on the information within the source code to fill in the documentation gap. This adds to the time required for the evaluation and ultimately to its cost. Furthermore, even when the documentation exists, tracking it down can often be very time consuming!
Two other areas under scrutiny during a product evaluation are related to Lifecycle Support and Configuration Management. Lifecycle Support examines the Product Release Process as a collection of activities by which a product is developed from its inception to its release. Configuration Management describes in detail the configuration management software and procedures instituted at the company to manage changes to its products. These two areas are very important for Common Criteria because they are a good indication of the level of care given by a vendor in the development of its product.
[Please note that terms “Lifecycle Support” and “Configuration Management” are used somewhat differently in the Common Criteria context than in the offering and provisioning of Oracle’s own Support Services, where those terms refer to the provision of specific types of support services to our customers. For more information, see http://www.oracle.com/support/index.html]
Both of these areas of the development process are very well established for all Oracle-developed products and based around Oracle’s development and integration management systems. My group has developed standard product evaluation documents covering both Lifecycle and Configuration for Oracle.
With newly acquired product lines, these standard documents will not apply and their equivalent for the acquired product lines usually do not exist. In my experience, few acquired companies previously had development practices and procedures as sophisticated as Oracle’s as they relate to the documentation required for a Common Criteria evaluation. Therefore it is necessary to establish what Lifecycle and Configuration methods have been used with the product prior to its acquisition by Oracle, and then document this afresh. In addition, in the case of the Lifecycle document, the degree to which the product has been assimilated into the Oracle bug fix lifecycle since its acquisition is one feature that has to be assessed.
A further product evaluation requirement is the Test Plan and Procedures document. This is needed to demonstrate that the security functions of the product have been thoroughly tested. Again, Oracle’s development system would provide the core of the testing for an Oracle developed product, but with an acquired product this will not be the case. In the case of many newly acquired companies, testing was manual or semi-automated and these activities needs now be individually documented, once again at extra time and cost for Oracle.
Regardless of the procedural and documentational gaps that may exist between the newly acquired company and Oracle, the knowledge and experience of the staff that join Oracle with the acquisition is essential to successfully understanding the product process, integrating that product process with Oracle conventions, and completing the product evaluation on time and budget.
With all these challenges, one may ask why Oracle goes to the trouble of submitting newly acquired product lines to security evaluations, and more importantly, how customers benefit from this extensive effort. Perhaps the greatest benefits of the Common Criteria evaluation for customers of products that were recently acquired by Oracle and submitted for evaluation is the increased scrutiny that Oracle brings to the source code and development practices of newly acquired products. A Common Criteria certification requires that extensive documentation about many aspects of product design and development be independently reviewed so that users can be assured of the inherent security quality of the software. For customers, these security certifications should be evidence of demonstrable security functions and attributes in the product.
Oracle now has over 30 security evaluations successfully completed and the Security Evaluations Team has more products currently undergoing Common Criteria evaluation. This demonstrates the focus that Oracle has given to security in its products.
More information on Oracle security evaluations can be found at http://www.oracle.com/technology/deploy/security/seceval/index.html
