Two DB Installation STIG items relate to the version of Oracle software in use:
Rule Title: Vendor supported software is evaluated and patched against newly found vulnerabilities.
STIG ID: DG0001-ORACLE11
Rule ID: SV-24339r1_rule
Vuln ID: V-5658
Severity: CAT I
Discussion: Unsupported software versions are not patched by vendors to address newly discovered security versions. An unpatched version is vulnerable to attack.
select banner from v$version where banner like ‘Oracle%’;
Rule Title: The latest security patches should be installed.
STIG ID: DG0003-ORACLE11
Rule ID: SV-24342r1_rule
Vuln ID: V-5659
Severity: CAT II
Discussion: Maintaining the currency of the software version protects the database from known vulnerabilities.
For Oracle Critical Patch Updates (CPU):
1. Go to the website http://www.oracle.com/technology/deploy/security/alerts.htm.
2. Click on the latest Critical Patch Update link.
3. Click on the [Database] link in the Supported Products and Components Affected section.
4. Enter your Oracle MetaLink credentials.
5. Locate the Critical Patch Update Availability table.
6. Identify your OS Platform and Oracle version to see if there is a CPU release.
7. If there is none, this check is Not a Finding. If there is one, note the patch number for the steps below.
View the installed patch numbers for the database using the Oracle opatch utility.
On UNIX systems:
$ORACLE_HOME/OPatch/opatch lsinventory –detail | grep [PATCHNUM]
On Windows systems (From Windows Command Prompt):
%ORACLE_HOME%\OPatch\opatch lsinventory –detail | findstr [PATCHNUM]
Replace [PATCHNUM] with the Patch number noted above. If the output shows the installed patch is present, this check is Not a Finding. No output indicates that the patch has not been applied and is a Finding.
What these mean is that it is important to only use current, fully supported versions of Oracle. This seems obvious, but a surprising number of systems in the real world never bother to update or patch, for fear of “breaking” something. While the importance of testing and validating updates and patches cannot be underestimated, the procedure itself is generally not complicated and can easily be incorporated into whatever normal release cycle the system. In my personal experience I can also say that in over 20 years of working with Oracle, while actual upgrades are occasionally buggy (i don’t recommend using the .0.1 or .0.2 release of any major version) and should undergo the most thorough testing, I have never personally had a problem with either the quarterly release of the Critical Patch Update (CPU, which contains security fixes only) or the Patch Set Update (PSU, which contains security and functionality fixes).
In the DOD world, these STIG requirements carry what amounts to the weight of the law: in order to stay with a particular version or patch level of Oracle, a technical justification must be provided and the system’s certification and accreditation document (the system’s Authority to Operate certification) must be approved by a number of reviewers. Waivers for quarterly Time Compliant Network Orders (TCNOs) must also be individually approved and acquired on a regular basis as new patches are released by Oracle. Given the level of bureaucracy involved, overcoming most technical challenges pales by comparison.
So in practice it is essential (and sometimes legally required) to stay current and patched at all times. When Oracle stops releasing patches for a particular version, an upgrade is necessary. These end of life dates are well publicized and announced years in advance, as well as included in the release documentation for every quarterly patch release, so every system should have time to adequately prepare.
Note: Oracle has recently announced that in the near future they are planning to discontinue the release of the Critical Patch Update, which includes only security fixes, and only release Patch Set Updates, which include functional fixes as well.
All quotations from the Database STIG taken from:
Defense Information Systems Agency. Oracle 11 Database Installation STIG Version 8 Release 1.10. http://iase.disa.mil/stigs/app-security/database/Pages/index.aspx. Published January 2014. Accessed April 4, 2014.