The Oracle Global Product Security Blog

Hi, this is Andy Webber. I am an ethical hacker in Oracle Global Product Security

I recently attended WikiSym2008. This conference was a great place to meet up with people interested in collaborative working and related technologies. I gave a presentation to share a recent experience my team and I had while reviewing Wiki extensions and plugins for security vulnerabilities.

In addition to providing a tool for collaboratively creating web content, Wikis are increasingly being used as a framework on which to build small applications. Many Wiki engines already provide limited support for this capability through extensions or plug-ins. These extensions will typically let developers use the Wiki engine in ways that were never envisaged by the original developers. Writing extensions is usually quite straightforward and generally gives a lot of freedom and access to the Wiki engine’s internal state and hence access to everything the Wiki engine has access to.

No matter how much care and attention the Wiki engine developers have put into making the wiki software as robust as they reasonably can, all these efforts may be undermined by any extension that has not been developed with the same level of care. The ease with which Wiki extensions can be developed means that anyone can develop and publish such extensions. Unfortunately, a large proportion of software developers are not properly educated about secure coding practices (See Mary Ann Davidson’s blog entry on this topic).

When we wanted to make more extensive use of extensions on one of our internal wikis, we performed some security reviews. It shouldn’t have been much of a surprise that we found quite a high proportion of the Wiki extensions we examined included potential security vulnerabilities. In most cases, these vulnerabilities were straightforward cross-site scripting or HTML injections. But, we also saw some other interesting possibilities like log injection attacks and inappropriate trust in 3rd party data.

[The work of the Ethical Hacking Team is not just about finding security bugs. The more interesting aspect of my job is to learn from these bugs, characterize them, understand why they happened, and establish methods for rapidly finding similar bugs. The most gratifying aspect of my job is helping development and testing organizations understand the security bugs, how to find them and fix them (and help ensure they don’t come back).]

After we found three or four vulnerabilities in a small set of extensions, we had a good characterization of what generally made these extensions vulnerable and what to look for in the code. We were then able to promptly review a large number (around 100) of extensions and quickly found that more than 20 of them were vulnerable. We reported these issues back to their respective developers (or Wiki engine maintainers) and, as a result, most of them have been fixed or withdrawn.

Even when educational institutions start to pay more attention to the security aspect of software development in their courses, it will be a long time before we can expect developers to consistently produce reasonably secure code. By analogy, I fasten my seat belt whenever I get in a car. Each time I get in a car I don't do a threat assessment and decide that a second to fasten the seatbelt is worth the effort compared to the risk of diving through the windscreen, or of being stopped and fined. I do it as a habit: a habit formed before it was a legal requirement and before I was able to appreciate the damage that flying through the windscreen might do to my future. Reviewing Wiki extensions for security vulnerabilities further highlighted that developers needed to form the habit of using bind variables in SQL queries, HTML/XML encoding output, etc.

Now, after this brief excursion into finding vulnerabilities in community-developed code, it's back to Oracle products for me.

For more information, see http://www.wikisym.org/ws2008/index.php/Security_of_Community_Developed_and_3rd_party_Wiki_Plug-ins

Hi, this is Eric Maurice again.

Oracle today issued an updated Security Alert related to the previously reported vulnerability CVE-2008-3257. The purpose of this updated Security Alert is to let WebLogic customers know about the immediate availability of the fixes on all supported platform and version combinations.

As we reported a week ago, Oracle felt that the nature of this vulnerability, which affected the Apache plugin for Oracle WebLogic, along with its publication in various public forums, and the availability of exploit code, warranted the issuance of an out-of-cycle patch. While this patch will also be included in the upcoming Critical Patch Update (scheduled for October 14, 2008), we recommend that customers apply the current patch as soon as possible, even if they have implemented the recommended workarounds.

For More Information:

The Security Alert for this vulnerability is posted on http://www.oracle.com/technology/deploy/security/alerts/alert_cve2008-3257.html

Oracle Software Security Assurance web site is located at: http://www.oracle.com/security/software-security-assurance.html

Critical Patch Updates & Security Alerts web site is located at: http://www.oracle.com/technology/deploy/security/alerts.htm

Hi, this is Eric Maurice.

Oracle today issued a Security Alert for a vulnerability affecting the Apache plugin for Oracle WebLogic (formerly BEA WebLogic). It is the first Security Alert since the introduction of the Critical Patch Update process in January 2005. Issuing this alert was required because the vulnerability and associated exploit codes have been posted in various public forums. This vulnerability has received the CVE identifier CVE-2008-3257. The CVSS score for this vulnerability is 10.0. It is remotely exploitable without authentication (i.e. it may be exploited over the network without the need for a username and password), and it can result in compromising the confidentiality, integrity, and availability of the targeted system.

When Oracle became aware of this issue, our security and development teams worked diligently to develop an effective workaround to prevent a successful exploitation of the vulnerability. Detailed instructions for this workaround have been posted on the eSupport site, and Oracle has already issued a Security Alert to all WebLogic customers to let them know about this workaround. In addition, Oracle will also issue an out-of-cycle security patch for this vulnerability as soon as the fix has been produced for all supported version-platform combinations. We expect this fix to be ready very soon, and we will issue an updated Security Alert to let customers know about its availability. In the meanwhile, we recommend that all customers implement the recommended workaround.

Unfortunately, the person(s) who published this vulnerability and associated exploit codes did not contact Oracle before publicly disclosing this issue. This means that the vulnerability was made public before providing Oracle an opportunity to develop an appropriate fix for this issue and notify its customers. In addition, the vulnerability was made public shortly after the publication of the July 15th Critical Patch Update, therefore prompting Oracle to issue an out of cycle security update.

For More Information:

Workaround instructions are posted on https://support.bea.com/application_content/product_portlets/securityadvisories/2793.html

The Security Alert for this vulnerability is posted on http://www.oracle.com/technology/deploy/security/alerts/alert_cve2008-3257.html

Oracle Software Security Assurance web site is located at: http://www.oracle.com/security/software-security-assurance.html

Critical Patch Updates & Security Alerts web site is located at: http://www.oracle.com/technology/deploy/security/alerts.htm

Hello, this is Eric Maurice again!

Oracle today released the July 2008 Critical Patch Update (CPUJul2008). While this is Oracle’s fifteenth Critical Patch Update (CPU), and personally, my ninth CPU (I joined Oracle in time for CPUJul2006), I am still impressed with the dedication and great talent of everyone who is involved with the production of each CPU. Over the years, Oracle has introduced many enhancements to the CPU and successfully extended its scope to many products added via acquisition.

Today’s CPU is characterized by two significant developments: the adoption of the Common Vulnerabilities and Exposure (CVE) numbering scheme, and the inclusion of the BEA, TimesTen, and Hyperion product lines in the Critical Patch Update. But more on these topics later! Let’s first have a look at the content of this CPU.

Today’s CPU include fixes for 45 new security vulnerabilities across a wide range of products: Oracle Database Server, Oracle Application Server (including Hyperion Peformance Suite), Oracle TimesTen, Oracle Enteprise Manager, Oracle EBusiness Suite, Oracle PeopleSoft Enterprise, and Oracle WebLogic Server. Eleven of these vulnerabilies affect Oracle Database Server, and none of these Database Server vulnerabilities are remotely exploitable without authentication. The criticality for these 45 new vulnerabilities fixed in the CPU range between the CVSS base scores of 1.5 to 6.8 (on a scale of 10). See our previous blog entry series for more information about CVSS and an explanation of the CVSS base scoring formula. Finally note that none of these 45 fixes affect client-only installations.

As mentioned earlier in this blog, this CPU is also characterized by the adoption of the Common Vulnerabilities and Exposure (CVE) system. As explained on the CVE program web site, “CVE Identifiers (also called "CVE-IDs," "CVE names," "CVE numbers," and "CVEs") are unique, common identifiers for publicly known information security vulnerabilities.” Starting with the July 2008 Critical Patch Update, Oracle will use these CVE identifiers to identify the vulnerabilities fixed in each new CPU, and will no longer use the proprietary numbering convention that was previously used in the CPU risk matrices. As a result, each new vulnerability fixed in the CPU will be assigned a unique CVE Identifier. This change was made possible because Oracle became a “Candidate Naming Authority” under the CVE program. Note that while the CPU documentation is the only authoritative source of information about vulnerabilities in Oracle products, and as such should remain the primary source of information about such vulnerabilities, the use of unique CVE identifiers should result in simplifying how Oracle vulnerabilities are identified in external security reports such as those produced by security researchers and vulnerability management systems. The use in the CPU documentation of CVE identifiers, along with the publication of the Common Vulnerability Scoring System (CVSS) base scores, is further evidence of Oracle’s customer focus in its vulnerability disclosure practices.

Finally, this Critical Patch Update also marks the inclusion of the BEA, TimesTen, and Hyperion product lines in the CPU process.

The inclusion of BEA in the CPU was particularly rapid because of the similarities that existed between the current CPU process at Oracle and the patching procedures previously in use at BEA. Furthermore, all involved in the CPU process have grown skilled with dealing with newly acquired companies, products (and people). The skillset with which Oracle successfully integrates acquisitions extends to all involved with Oracle Software Security Assurance.

Today, the CPU process provides a cohesive program for the patching of hundreds of Oracle products across many various platforms. Developed with customers in mind, the Critical Patch Update provides a predictable patching schedule that is designed to fall outside of typical blackout dates experienced by most customers (such as end of fiscal year, end of calendar year, etc.) As a result of this predictability (CPUs are issued on the Tuesday closest to the 15th of the months of January, April, July, and October), Oracle customers can leverage normal maintenance windows for deploying security updates to Oracle products, thus reducing interruptions to their production environment.

For More Information:

Oracle Software Security Assurance web site is located at: http://www.oracle.com/security/software-security-assurance.html

Critical Patch Updates & Security Alerts web site is located at: http://www.oracle.com/technology/deploy/security/alerts.htm

The CVE web site is located at: http://cve.mitre.org/

Hi, this is Eric Maurice again.

The greatest external factor influencing Oracle Software Security Assurance is the feedback we receive from customers. While members of Oracle’s Global Product Security team have daily interactions with customers, security researchers, or industry analysts, the most exhaustive channel for customer feedback is the Security Customer Advisory Council that is being managed by the Program Management Office of the Global Product Security organization.

The Security Customer Advisory Council (SCAC for short) is comprised of customers from around the world and representing various industries. Moreover, SCAC members are collectively using most if not all Oracle products. The SCAC meets at least once a year to discuss emerging security topics, Oracle’s security strategy, and Oracle Software Security Assurance programs, including the Critical Patch Update and related activities. For example, the recommendations of the SCAC have previously led Oracle to adopt the Common Vulnerability Scoring System (CVSS) as a standard way to rate the severity of the vulnerabilities fixed in the CPU and to issue pre-release CPU announcements (these are issued on the Critical Patch Updates and Security Alerts page the Thursday before the CPU due date).

Most recently, the Independent Oracle User Group (IOUG) joined the Security Customer Advisory Council. This initiative was launched by the Enterprise Best Practices SIG under the leadership of Michelle Malcher, the SIG president. As a component to this initiative, Oracle and IOUG also produced a number of security training webcasts. These webcasts are available online on the Enterprise Best Practices SIG Download Page. The two most recent webcasts were particularly popular! In March, Daniel Wong (Director of Engineering the Database Security group) presented the security enhancements in Oracle Database Server 11g. Last month, Jenny Tsai-Smith (Senior Director in Curriculum Development) and Mark Fallon (Director of Software Development) recorded a webcast on how to best prevent SQL Injection attacks.

In preparation for the next Security Customer Advisory Council (to be held in October), the Enterprise Best Practices SIG of IOUG posted a security survey to try to gather information about the current security practices of its members, particularly around the application of the Critical Patch Updates and Patch Sets and to gather recommendations from members about possible process improvements that Oracle could bring to further enhance Oracle Software Security Assurance activities. Michelle and I recorded a webcast that discuss the objectives of the survey. We went through two iterations of the survey, further fine-tuning it, to come up with a shorter, simpler survey, that drill down to areas that are most likely to yield feedback from Oracle users (the current survey is titled “OSSA Security Survey II” on the IOUG web site).

We would like to encourage all Oracle users to take this survey!!! (Remember to select “OSSA Security Survey II”). A Free Associate Membership to IOUG may be required to take the survey, but completing this form should take no more than five minutes. Completing the survey itself should take no more that ten minutes (unless you decide to take advantage of the free form question at the end of the survey by writing an extensive set of recommendations for Oracle).

Information about the Security Survey:
The survey is located at http://survey.ioug.org . (Please select “OSSA Survey II”.)
The webcast explaining the objectives of the survey is located at: http://www.ioug.org/networking/SIGs/SurveyPodcastrev.mp3

Information about Oracle Software Security Assurance:
For more information about the Security Customer Advisory Council, you can e-mail: securityCAC_ww@ORACLE.COM

Information about IOUG:
IOUG web site is located at http://www.ioug.org.
For information about IOUG membership, see the IOUG membership page.
Recorded IOUG webcasts can be found at http://www.ioug.org/networking/SIGs/Archived_SIG_Webcasts.cfm

This is John Heimann, Sr. Director, Oracle Global Product Security (GPS), again.  In my role as manager of the GPS Security Program Management team, one of my primary concerns is ensuring that Oracle�s products effectively protect sensitive customer data.  More specifically, the Security Program Management team helps to ensure that Oracle product development groups consistently apply secure coding standards, tools and processes that help reduce the likelihood of exploitable security vulnerabilities in our products.  Oracle product development groups have designed and implemented many security features that customers can use to protect sensitive information.  My team works with product groups to help ensure that Oracle developers avoid security flaws that could allow attackers to bypass these security features and gain access to sensitive data.

In recent years, there have been a number of high profile breaches of information systems that process sensitive information associated with thousands or even millions of people. When Oracle GPS becomes aware of breaches of information systems processing sensitive data, we typically investigate the causes of the breaches.  Even if the breached information system did not include any Oracle technology, analyzing root causes of a breach can allow us to help improve the design of our products, avoid certain classes of vulnerabilities, or improve the security guidance we offer to customers. 

There are cases where understanding why a serious data breach was so serious require extending the breach analysis beyond the boundary of the information system. In those cases, the analysis includes how the people and systems outside the breached system use the information that was revealed.  Sometimes, the analysis indicates that certain categories of data considered �sensitive� or �private� when they were defined - often in a pre-internet, or even pre-computer, era - are now used in ways that are fundamentally insecure.  The fact that those types of data are now processed by internetworked computer systems simply highlights that insecurity, and makes exploitation of it easier. 

As a concrete example, suppose I told you that you are required to use a system that is responsible for managing your personal identity, tax history, past credit records, ability to get future credit, and other important functions in your daily life.  You will be issued a unique password to access that system, and you can NEVER change it.   Contrary to typical password best practices, the password has well-known internal structure that may make components of it predictable. Moreover, you are required to give that password to banks, credit companies, utilities, the US Internal Revenue Service and other government agencies, tax preparers and accountants, and every employer you have ever worked for.  Would you agree to use such a system?   You probably would not, but that's exactly what we in the US are required to do with our social security numbers (SSNs).  We pretend that SSNs are "private" information but given the number of people to whom we disclose SSNs, they should not be considered private.

A similar situation exists with credit card numbers. If I know your credit card number and date of card expiration, I can make purchases by phone or on the Internet that will be charged to your credit card account. You can change a credit card number on a time scale of months or years - by canceling the card and applying for a new one - but on a short term time scale a credit card number is effectively fixed and unchangeable, and you have to reveal it to hundreds of people and computer systems every month.  How would anyone possibly consider that information "secret?�  Note that credit cards now have three digit Card Security Codes (CSCs) printed on the back to protect against fraudulent use of credit card numbers.  Merchants often ask for a CSC when a customer does not present a physical card during a purchase (e.g., when ordering something by phone or on the internet).  Since the CSC number is fixed for the life of a card, can be obtained by any merchant who handles a customer�s physical card, and must be disclosed any time a customer makes an internet or phone purchase, it can�t be considered truly secret either.  We pretend that SSNs and or credit card numbers are �private� or �secret� and have to be protected by elaborate computer security mechanisms, but in fact they have never been truly secret.

The real problem is that our social systems associated with identity and credit allow an attacker with simple knowledge of Joe Blow's SSN or credit card number to masquerade as Joe Blow and perform some privileged function, like making a purchase on Joe's account.  Computers make attacks that were already in existence (like dumpster diving for credit card slips with card numbers, or paystubs with SSNs) much easier, and simply underscore the weakness in the greater system that handles the information, including people and processes as well as computers.

At one point in time, when credit card or SSN data were disclosed to a limited number of human users through manual processes, simply demonstrating knowledge of an SSN or credit card number may have been an acceptably secure means of authentication.  Unfortunately for those of us who still must use SSNs and credit cards, simple knowledge of SSN or credit card number cannot now be considered a secure means of user authentication.  In fact, such practice violates several basic, generally accepted principals for secure authentication.  Among these principals are

• 
  
  data used for authentication purposes must not be widely shared or stored in multiple places


• 
  
  authentication data should not be difficult or impossible to change


• 
  
  authentication is much more secure when it involves something you have, or something you are, in addition to something you know.

Note that the weaknesses associated with SSNs and credit card numbers have been recognized for many years, and in the case of payment card information were one of the reasons for the creation of the Secure Electronic Transcation (SET) protocol in 1996.  The SET protocol never became established because in the late 1990s, the rate of fraud associated with the existing process (simply giving your credit card number to a merchant) didn't justify the added expense and overhead of using SET.  I suspect that over time, as more fraud associated with phone or online credit card sales occurs, people will re-examine the basic problem associated with using static credit card information and consider more sophisticated mechanisms for user authentication in payment transactions.  Similarly, as identity theft becomes more common, I expect we will start to see a more complex mechanism than simple knowledge of a permanent SSN to evolve for authenticating users to potential payees.

Preventing exploitation of information by improving the security of computer systems in which that information is managed is not enough!  In many cases, the information itself, and/or how it is used in social processes that include but are not limited to computer systems, needs to change before that information can be used securely.  Properly planning and documenting business processes, including the definition of the information being maintained in the organization and defining what constitutes appropriate use of the information is required as a pre-requisite to defining a sound IT security strategy.

Hi, this is Eric Maurice again.

A number of publications recently reported about a new way to hack Oracle databases.  These articles were in fact referring to a recently published paper by David Litchfield, titled Lateral SQL Injection: A New Class of Vulnerability in Oracle. 

SQL Injections are a very well known class of attacks, which can affect virtually any relational databases when no or insufficient input validation has been implemented.

In simple terms, SQL Injection attacks are designed to leverage improper coding of database-powered applications that, in the absence of proper input validation, allow a malicious attacker to insert string input to an application. In such scenario, an attacker can "inject" or pass on harmful SQL commands, which will then be executed by the back-end database. The consequences of successful SQL Injections can be severe: an attacker could gain access to sensitive data, manipulate database information, and in some instances, change the structure of the database, deny legitimate access to it, or grant unauthorized privileges to himself or to others. Web applications are particularly at risk because -- exposed to the Internet -- they often allow an attacker to perpetrate SQL injection attacks without being authenticated to the targeted database or application.

An important aspect of Oracle Software Security Assurance is sharing security information and recommended practices with customers so that they can optimize their security posture. We recently posted a SQL Injection tutorial online that demonstrates how to properly implement input validation controls and prevent this kind of attacks.

In his paper, David explains that in certain circumstances, SQL Injections can also take place in procedures that are not intended to take user input. Note however, that in such a scenario, setting up the attack requires that the attacker had been previously granted a database account with necessary privileges. David concludes that it is doubtful that this kind of attacks becomes:exploitable in the normal sense.

While some may consider the topic of Lateral SQL Injections as mostly academic, and relevant only for the security researchers community, I think this paper has the merit of further raising the awareness of database administrators and programmers to SQL Injections. SANS and others have flagged this class of attacks as a primary threat for database-driven sites and applications. In my opinion, proper input validation constitutes a required security practice that needs to be extended to all functions and procedures, whether they are expected or not to take user input. Furthermore, as expressed in the SQL Injection training and in the Oracle documentation, bind variables should be used as much as possible.

As discussed above, SQL injection happens when a dynamic SQL statement is constructed from user input. In the case of the attack discussed in David's paper, the dynamic SQL statement is being constructed from data stored in the database. The values are then being converted into character strings based on a template provided by the system. It is this template, as opposed to the stored value, that controls what will be injected.

When bind variables are properly used, the bind variable name is physically part of the SQL statement, but this bind variable is used as a reference to the rendered value. As a result, the rendered value is never interpreted directly as part of the SQL statement; therefore no SQL Injection can take place.

In some instances, like DDL operations where a database object needs to be constructed, Oracle administrators do not have the option of using a bind variable. In this instance, the DBMS_ASSERT package should be used to correctly handle the rendered value, either ENQUOTE_LITERAL when it is going to be used as a literal or ENQUOTE_NAME when it is going to be used as the name of a SQL object.

For more information, see the online tutorial Defending Against SQL Injection Attacks.  Information on Oracle Software Security Assurance is available on Oracle.com. 

Hello, this is Eric Maurice! 

Oracle today released the April 2008 Critical Patch Update (CPUApr2008).  This Critical Patch Update (CPU) addresses a total of 41 vulnerabilities affecting Oracle Database Server, Oracle Application Express, Oracle Application Server, Oracle E-Business Suite, Oracle Enterprise Manager, Oracle PeopleSoft Enterprise, and Oracle Siebel CRM Applications.  Fifteen of these vulnerabilities are specific to Oracle Database Server (an additional two affects Application Express).  Note however that a number of these Database Server vulnerabilities affect optional Database Server components, and only one of these Database Server vulnerabilities can be remotely exploitable without authentication.

While none of the Oracle Database Server fixes requires patching the database client-only installations, this CPU includes one fix for Oracle Application Server client-only installations.  As with the previously released January 2008 CPU, this CPU includes an Application Server client fix to address a vulnerability affecting JInitiator, a web browser extension that enables end users to run Oracle Forms Services applications within their browser.  This vulnerability only affects version 1.3.1.14 and earlier versions of JInitiator.  Just like the previously fixed JInitiator vulnerabilities, this vulnerability has a CVSS score of 9.3 because it could allow an attacker to gain full control of the targeted client (e.g. workstation) at the Operating System level, but it cannot result in a compromise of the server component. 

This fourteenth CPU also marks another milestone!  For the first time, the CPU includes fixes for Oracle�s Siebel CRM Applications.  As a matter of policy, Oracle tries to synchronize the release of the security patches of acquired product lines with the CPUs, and ultimately ensure that new product lines join the CPU process (in the way that PeopleSoft, JD Edwards, and now Siebel have). 

The CPU fixes for Siebel CRM Applications will be cumulative for the product line in which they apply (There are currently four supported product lines).  This will allow customers who have previously skipped security patches to quickly catch up by applying the most current CPU. 

The inclusion of Siebel Enterprise products in the CPU process provides former Siebel customers with a number of benefits.  Under the Siebel model, security fixes were typically included, along with non-security fixes, in the �Fix Packs�.  The most significant vulnerabilities could also be fixed with dedicated ad hoc (unscheduled and non-cumulative) fixes.  The inclusion of Siebel Enterprise products in the CPU process therefore provides customers enhanced visibility to security fixes.  In addition, customers benefit from the predictability of the CPU schedule, thus potentially reducing the cost of security management in their environment.

The Critical Patch Updates and Security Alerts page on Oracle Technology Network provides detailed information about this CPU, as well as previous CPUs and Security Alerts.  Oracle Technology Network also hosts additional information about Oracle�s implementation of the CVSS 2.0 standard and a glossary of the terms used in the Risk Matrices in the CPU Advisory.  The Resource Library on the Oracle Software Security Assurance web site also provides a number of links to useful security resources.

Hi, this is Eric Maurice!  This very short blog to let you know about recently recorded podcasts and webcasts on Oracle Software Security Assurance topics.

We recently recorded a podcast interview with Oracle CSO, Mary Ann Davidson.  In this podcast, Mary Ann discusses the importance of Oracle Software Security Assurance, the role of Oracle�s Global Product Security Group, and some of the changes that were introduced with the Critical Patch Update. 

Oracle and the Enterprise Best Practices Special Interest Group (SIG) of the Independent Oracle User Group recently delivered a one hour webcast introducing Oracle�s secure configuration initiative and discussing the security enhancements in Oracle Database 11g.  In this webcast, Daniel Wong, Director of Engineering for Database Security at Oracle, discusses in technical detail the security changes introduced in the default configuration of Oracle Database Server with 11g.  Such changes affect the default audit settings, authentication and password management, and access control changes to certain UTL packages, etc.  Daniel then provides security recommendations for customers who are looking at upgrading (or have upgraded to) Oracle Database 11g.  A previously recorded webcast providing technical recommendations for securely configuring Oracle databases is also available on the IOUG website under the archived SIG webcasts section. 

Note that a registration to IOUG�s web site may be required to access some of this content (FREE membership to the Enterprise Best Practices SIG is also available here).

For more information:

Mary Ann Davidson�s interview is available here.

IOUG�s webcast on Oracle Database 11g security is available here.

IOUG�s webcast on securely configuring Oracle databases is available here.

Oracle Software Security Assurance Resource Library is available here.

The download page for IOUG�s Enterprise Best Practices SIG is available here.

Hello, I'm Petra Manche!  I work in the Security Evaluations team in Oracle's Security Assurance Group.  Security Evaluations are a critical part of Oracle Software Security Assurance, and my team is responsible for managing the independent security evaluations of all Oracle products

Oracle recently completed the evaluations of Oracle Database 10g Release 2 (10.2.0.3) and Oracle Label Security 10g Release 2 (10.2.0.3) against Common Criteria assurance level EAL4+ and against the U.S. Government Protection Profile for Database Management Systems in Basic Robustness Environments (Version 2.1).   As usual Oracle evaluated the Enterprise Edition of the Database, but for the first time we also evaluated Standard Edition and Standard Edition 1.  Real Application Clusters (RAC), Enterprise Users, and Partitioning were also included with these evaluations for the first time.

For those who don't know what Security Evaluations are: independent bodies (laboratories) examine Information Technology products and systems, and if the examination is passed, a certificate is awarded (usually by a government body).  This process provides confidence in the security of the Evaluated products to end users, including government and military institutions.

Oracle has a long history among IT vendors of having security evaluations performed on its products.  Since committing to the security evaluation process in 1990, Oracle has successfully completed 29 security evaluations.  Many of the early evaluations were on Oracle Database Server, but more recently we have extended our scope and evaluated other products including Oracle Enterprise Linux, Oracle Application Server and Oracle Internet Directory. 

Oracle is currently committed to evaluating its products under two industry standards:

-         FIPS 140 for cryptographic modules, and

-         Common Criteria for Information Technology Security Evaluation. 

FIPS stands for Federal Information Processing Standard.  The full title of FIPS 140 is �FIPS 140-2: Security Requirement for Cryptographic Modules.�  It is published by the U.S. National Institute of Standards and Technology (NIST).  Hardware, firmware or software cryptographic modules are all tested and validated against the standard.  The cryptographic algorithms are NIST approved.  FIPS 140-3 is currently being drafted and representatives from Oracle will attend the upcoming FIPS 140-3 Software Security Workshop.

Common Criteria (CC) is also known as ISO standard 15048.  The full title of the standard is �Common Criteria for Information Technology Security Evaluation".  The Common Criteria is a single framework of evaluation criteria for products or systems.  It is designed to look at the whole development lifecycle: from design, implementation, testing to delivery and installation of the product or system by a third party, in order to provide assurance that development practices have been documented, followed and enforced correctly.

A common misconception about the Common Criteria is that the entire product is always evaluated in this process.  In fact, it is the security-related functions and the parts of the product that interact with those security functions that are evaluated.  These make up the scope of the evaluation, a.k.a. �Target of Evaluation�.  The product is installed in an evaluated configuration, whereby some of the product functionality may be disabled but the product must be able to function normally.  Information on what exactly has been evaluated is found in a document called the �Security Target�.  This document is publicly available once a product has been certified.  Security Targets for Oracle software are available on the Security Evaluation page on Oracle Technology Network.

To date Oracle has completed four FIPS 140 validations and 15 Common Criteria evaluations.  A listing of the evaluations that have been obtained or are currently underway can be found on Oracle�s Security Evaluation status page. 

Note that Oracle not only performs evaluations, but it is also actively participating in the development of the Common Criteria.  Oracle is a member of the Common Criteria Vendors Forum (CCVF) that works with the Common Criteria International organisations to enhance the Common Criteria and address common issues within the criteria.  In a previous blog entry, Duncan Harris discussed some of the limitations with the current version of the Common Criteria. 

More information on Oracle Software Security Assurance is available on Oracle.com.  The Security Evaluation page on Oracle Technology Network provides detailed information about Oracle's involvement with Security Evaluations.