Oracle Critical Patch Update Documentation Improvements

The Oracle Global Product Security team has announced some new changes to Oracle's quarterly Critical Patch Update (CPU) documentation. Organizations face a huge challenge in attempting to prioritize and determine the impact of each CPU, especially in complex application environments (like Oracle Applications 11i) where multiple patches must be applied.  The new changes to the CPU documentation are aimed at providing additional information to help organizations prioritize CPU patches.  These enhancements may satisfy a few Oracle critics, but most are looking for more detailed information on each vulnerability.

There are three enhancements for the October 2006 CPU -

1. A high-level executive level summary - This will be interesting to read as Oracle intends it to be suitable for "executive management and other non-IT groups."  With the large number of vulnerabilities in each CPU, it will be difficult to provide much detail. Most likely, the summary will only highlight the most critical vulnerabilities.
2. Remotely exploitable vulnerabilities highlighted - These vulnerabilities could be determined by carefully analyzing the CPU risk matrix, but now will be clearly marked.  I am not sure how much of a difference this will make for a few reasons - (1) few of the Oracle Database security bugs are remotely exploitable (usually SQL*Net related), almost always authentication is required to exploit the vulnerability, (2) many of the Oracle Application Server bugs are remotely exploitable, and (3) the database and application server patches are all encompassing, so it is not possible to patch a single vulnerability.  This will be most important for Oracle E-Business Suite patches, which are individual patches.
3. Common Vulnerability Scoring System (CVSS) Base Metric Group score for each vulnerability - CVSS is an attempt to "standardize" the definition of a vulnerability's severity.  I am not sure how organizations will use the CVSS scores (e.g., if it is a 3.0 or higher we patch).  It will be interesting to see how useful the CVSS scores are and how organizations use them.  A nice calculator is available here to see an example score.  You can use the calculator to determine the "Environmental Metric" and "Temporal Metric" for your environment.

I see several potential issues with the documentation enhancements -

• A major emphasis is placed on remotely exploitable vulnerabilities.  DBAs are looking for any excuse to delay or not apply CPUs due to the complexity and effort required, so no remotely exploitable vulnerabilities in a CPU may be all some DBAs need to postpone this quarter's security patches.  By emphasizing remotely exploitable vulnerabilities, the totality of the seriousness of each CPU may be diminished.  Since all Oracle Databases should be protected by a firewall from the Internet, the most significant threat is from internal users who most likely will have a database account or may be able to access the database through an application proxy account (i.e., think APPLSYSPUB for Oracle Applications 11i).  Also, SQL injection is a common attack vector for Oracle Databases.
• The CVSS metric has a heavier weighting toward "Authentication Not Required" and equally weights for Confidentiality, Integrity, and Availability impacts.  Thus as with the above emphasis on remotely exploitable vulnerabilities, a few vulnerabilities will receive significantly higher scores and focus.  Calculating some of the scores for the July 2006 CPU, I don't see an immediate benefit from the scores in helping to prioritize the CPU patches.  They are a nice to have, provide a metric for senior management, and may be useful in comparing to other vendor patches (e.g., Microsoft), but I don't see the scores impacting the patching decision or process.
• The Oracle E-Business Suite 11i patches are not linked to a specific vulnerability in the CPU documentation, so the CVSS metric information is not useful for these patches.  Hopefully, Oracle will provide the mapping, so customers can actually prioritize these patches.
• Oracle's stance with the CPUs is that you need to apply all the patches ASAP.  I don't see this changing, therefore, the bias of the CPU documentation will be toward the severity of vulnerabilities and the need to patch.  Only when Oracle is advising customers to prioritize specific patches due to severity (such as apply the Application Server patch now and then apply the Database patch during the next downtime) will any of this information be useful.  In complex application environments, like Oracle Applications 11i, it is very difficult to regression test and apply all the patches at once.

Overall, the changes to the CPU documentation will provide most organizations only minor benefits.  These enhancements may help mid-level management to better sell the need to apply the CPUs in a timely manner to top executives.  Hopefully as Oracle improves the CPU process and documentation, Integrigy will no longer have to publish our own analysis of each CPU.