By Ray Smith

Oracle provides risk matrices for all of its products with quarterly Critical Patch Updates (CPU) (recently changed to Security Patch Updates (SPU)). This article provides some guidance about how the Oracle Database Risk Matrix can be interpreted, but the interpretation and implementation decisions rest with the Oracle professional and their corporate security staff.

Each Oracle Database Risk Matrix lists specific risk vectors treated in the current patch set. Analysis of the Risk Matrix for your environment should be based on the potential impact of those risk vectors on your systems.

Risk Exploits

Risk exploits are discovered from a variety of sources: Oracle employees, users, security specialist firms and hackers themselves. Exploits are posted to public websites (described later in this article) as they are discovered. The Database Risk Matrix lists each exploit with scores assigned on several risk vectors to help you evaluate the risk in your environment, as illustrated in Table 1.

Risk Matrix Elements

Each risk is defined and scored using industry standard evaluation criteria and posted to the Risk Matrix and associated notes.

CVE#

Comment vulnerability and exposure (CVE) numbers are assigned and cataloged on the CVE site as: “International in scope and free for public use, CVE is a dictionary of publicly known information security vulnerabilities andexposures. CVE’s common identifiers enable data exchange between security products and provide a baseline index point for evaluating coverage of tools and services.”

The Oracle Risk Matrices reference all exploits by CVE reference number acts as a starting point for your analysis. Each vulnerability is registered with the National Vulnerability Database as they are discovered. This publicly available database is online at http://nvd.nist.gov.

Component and Protocol

The impacted Oracle component and the affected protocol are listed next. This combination can be used to quickly determine whether the risk applies to your environment. For instance, risks listed through vulnerabilities in the RDBMS parallel query option can be ignored if you don’t use it in your environment. You can also use these two columns to target patching when the opposite situation exists (decision to patch only databases with parallel query option). Best practice, of course, is only to install only database components that areneeded by your application.

Package and/or Privilege Required

This column can define limits of a potential exploit. Exploits requiring advanced privileges (DBA role or SELECT ANY OBJECT, for instance) can be offset by managing and monitoring the privilege directly. Exploits requiring simple or no privileges pose the broadest risk.

Remote Exploit Without Authorization

This category of threat is as dangerous as it sounds. Typical database security protects your environment to a large extent when authorization is required to exploit the vulnerability. A “No” in this column indicates that anyone with network access can hack your database.

CVSS Version 2.0 Risks

The Common Vulnerability Scoring System (CVSS) was developed and is supported by network and hardware vendors to provide a consistent objective tool for risk evaluation. Scores range from zero to 10, with 10 being the most dangerous. CVSS scores are based toward protecting root access, so risks posing the greatest threat to root functionality score highest. Databases generally provide protection against root-level attacks, so CVSS Base Scores for Oracle databases generally receive mid- to low-level scores. Do not rely solely on the base score to determine your patching strategy. Elements in the CVSS section can be grouped into technical and impact values.

Technical Risk Elements: Access Vector, Complexity and Authentication

Access Vector

Threats are generally exercised through network connections or may be exploited locally, either on the server or from within the database.

Access Complexity

The complexity of the threat may have a direct bearing on the urgency you associate with a particular threat. There is an active publishing movement on the web sharing details of new exploits as they are invented. Many attacks originate inside an organization’s firewall, so “low” access complexity hacks may pose a greater risk than “high” complexity threats in many organizations.

Authentication

Security at each level of your infrastructure is designed to prevent attacks by requiring authentication to enter the network, log into a server and access a database. This risk aspect gauges the likely effectiveness of authentication.

Impact Values: Confidentiality, Integrity and Availability

All three of these elements provide insight into the potential effect on the confidentiality of your data, the integrity of the data or the hacker’s ability to change it, and system availability. Each element is rated None, Partial and Complete. Oracle’s definitions in the Appendix provide more detail and explanation of these scores.

Notes:

1. The CVSS Base Score is 10.0 only for Windows. For Linux, Unix and other platforms, the CVSS Base Score is 7.5, and the impacts for Confidentiality, Integrity and Availability are Partial+. For information, refer to Patching for CVE-2012-3137, My Oracle Support Note 1493990.1

In some configurations, client-side updates for Database, Enterprise Manager Grid Control, WebLogic Server and Fusion Middleware are recommended. For information on what patches need to be applied to your environments, refer to Critical Patch Update October 2012 Patch Availability Document for Oracle Products, My Oracle Support Note 1477727.1

2. The vulnerability affects Unix and Linux platforms only.

Supported Versions Affected

Supported database releases affected by each threat and resolved by the patchset are listed in this column.

Notes

Reference to off-matrix notes are made in the last column. These notes are particularly important when your environment is mentioned or specifically excluded in the note. Notes should be evaluated in context with the rest of the values under consideration.

A Model for Analysis

In the author’s environment, we gather all the information in a spreadsheet consisting of separate blocks for each line of the Database Risk Matrix for each Critical Patch Update. The spreadsheet provides documentation of the analysis and recommendations forming the patch strategy.

Step 1: Paste the Risk Matrix

Pasting the actual line from the risk matrix into the spreadsheet provides a consistent, convenient reference for analysis.

Step 2: Gather References

Each CVE reference has a corresponding page on the National Vulnerability website. For example, the CVE# for this illustration is referenced in the URL below:

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-3137

We copy the vague description from the NVD website onto the spreadsheet so we have a description of the threat on copy. A Google search for “CVE-2012-3137” yielded 37,600 links during the writing of this article, so much more informationis available online.

We also paste the Risk Matrix notes into this block.

Step 3: Perform the Analysis and Research

Sometimes the easiest way is to start at the outside columns and work your way in.

• Do you use the component named?
• Is the specific protocol used in your environment? Threats are often isolated to specific licensed and advanced options.
• Do your applications utilize the package or grant the privilege listed?
• Are you running any of the database versions listed?
• Do any of the notes relate to your environment or affect your evaluation of the risk? If the risk pertains to your environment, evaluate the technical aspects of the risk.
• How difficult does it appear to make the attack in your environment?
• Does it apply to authenticated users or the general public?

Finally, determine the criticality of the risk by evaluating the potential impacton your data and decide how much additional information you need to make your recommendation.

Step 4: Summarize Your Analysis

Your answers to the analysis above should be documented in the analysis section of the spreadsheet. List any open items that require further consideration.

Step 5: Make a Recommendation

Your evaluation of the quarterly security patch could form the basis of your patching solution or it may be used for documentation for system security audits. Your judgment is the most important factor, because you know your environment better than anyone else.

Maintaining a Secure Environment

The analysis in this article covered the quarterly threat evaluation process. Remember, as you perform your analysis, all CPU/PSU patch sets arecumulative. Many companies do not apply each quarterly patch. As a result, threats for each new patch set should be evaluated in addition to “open” risk exploits that were left unpatched from earlier CPUs.

Finally, apply the latest CPU/PSU any time you upgrade a database or install fresh binaries. New bugs are discovered daily, and you should assume that any installation binaries will contain bugs. Take the time to run opatch.

This article discussed evaluation of quarterly patchsets. It’s strongly recommended that you and your team develop a process for patching and applying the patches on a regular basis, so that you can respond quickly and effectively when a high-risk patch is released. A regular patch schedule, along with analyzing the risk of the exploits, should be developed to consistently apply patches and make for a secure environment.

Appendix

Source: MOS Note 394487.1 Use of Common Vulnerability Scoring System(CVSS) by Oracle

Interpretation of “Complete”

CVSS rates Confidentiality, Integrity and Availability impacts as None, Partial or Complete. The definition of Complete is defined in terms of the impact to the system. Oracle products run on an operating system, so the system can be considered to be:

• just the Oracle software running on a machine; or
• all software running on the machine.

The former interpretation makes sense in environments where the only important information is maintained by Oracle software. For example, a machine installed with Oracle software and a minimal operating system whose only purpose is to run that software. A vulnerability that leads to operating system super-user privileges provides little benefit over a vulnerability that leads to super-user privileges for just the Oracle software.

The latter interpretation makes sense for scenarios in which Oracle software is not the only application on a machine. In this scenario, a vulnerability that leads to operating system super-user privileges compromises all applications. A vulnerability that leads to super-user privileges for just the Oracle software is less severe.

A sampling of CVSS ratings for vulnerabilities on NIST’s NVD website reveals that different interpretations of Complete are being used, but that the latter is more common. Oracle has adopted the latter interpretation to be consistent with the general use of CVSS.

Addition of Partial+ Rating

• Oracle provides additional information on Partial ratings as follows:
• Partial, which maps to the Limited value used in CPUs prior to the adoption of CVSS; and
• Partial+, which maps to the Wide value used in CPUs prior to the adoption of CVSS.
• The definition of Limited and Wide used in Critical Patch Updates before the adoption of CVSS are:
• Limited: the exploit affects a limited range of resources (e.g., a specific database table)
• Wide: the exploit affects a wide range of resources (e.g., all database tables)

We will use these definitions as a starting point for Partial and Partial+. We are not changing the CVSS base metric scoring system. However, customers have all the required information to recalculate the CVSS score with Partial+ ratings changed to Complete, if that is more appropriate for their environment. Customers who do not wish to deal with this level of complexity can simply treat Partial+ as Partial.

References

Common Vulnerability Scoring System standards guide on the Forum for Incident Response and Security Team (FIRST)

http://www.first.org/cvss/cvss-guide.html (latest version of standard)

http://www.first.org/cvss/v1/guide.html (CVSS version 1.0)

Oracle Critical Patch Updates and Security Alerts page

http://www.oracle.com/technology/deploy/security/alerts.htm

National Institute of Standards and Technology (NIST) National Vulnerability Database (NVD)

http://nvd.nist.gov/CVSS

Calculator on NIST NVD website

http://nvd.nist.gov/cvss.cfm?calculator&version=2 (CVSS version 2.0)

http://nvd.nist.gov/cvss.cfm?calculator (CVSS version 1.0)

OSSA website

http://www.oracle.com/us/support/assurance/index.html for blogs on the CPUs and best practices whitepapers

About the Author

Ray Smith is actively engaged as a volunteer for IOUG. He has served on COLLABORATE and Oracle OpenWorld, and is on the SELECT Journal Editorial Board. He currently works as a senior Oracle DBA/technologist for Portland General Electric in Portland, Ore. He is also an Oracle ACE.