Tags

, , ,

Oracle provides risk matrices for all of its products with the quarterly Patch Set Update (PSU). This article provides some guidance about the Database Risk Matrix can be interpreted, but the interpretation and implementation decisions rest with the Oracle professional and their corporate security staff.

Each Database Risk Matrix lists specific risk vectors treated in the current patchset. Analysis of the Risk Matrix for your environment should be base 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 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 Figure 1. 

Link to the Jul2014PSU page:

http://www.oracle.com/technetwork/topics/security/cpujul2014-1972956.html

 

RiskMatrix_Illustration1

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 and exposures. 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 (decisioj to patch only databases with parallel query option, f.e.).

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

Yes, 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 0 – 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.

Element 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. Since many attacks originate inside an organization’s firewall, ‘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, Availability

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

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.

 

A Model for Analysis

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

RiskMatrix_Illustration2

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 as this article was drafted, so much more information is available online.

We also paste the Risk Matrix Notes into this block.

Step 3- Perform the Analysis and Perform 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 impact on 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 judgement is the most important factor because you know your environment better than anyone else.

Maintaining at Secure Environment

The analysis in this article covered the quarterly threat evaluation process. Remember, as you perform your analysis, all CPU/PSU patchsets are cumulative. Many companies do not apply each quarterly patch. As a result, threats for each new patchset should be evaluated in addition ‘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.

 

Appendix 1

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 web site 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)
National Institute of Standards and Technology (NIST) National Vulnerability Database (NVD)
  http://nvd.nist.gov/
CVSS Calculator on NIST NVD web site
  http://nvd.nist.gov/cvss.cfm?calculator&version=2 (CVSS version 2.0)
  http://nvd.nist.gov/cvss.cfm?calculator (CVSS version 1.0)