The next CAT I STIG control in this series is less technical and more about policy. Like all of the others, however, it requires the DBA to be aware of things beyond their immediate day to day workload, and involved in the planning, design, and development of the system technology stack.
V-61539: Oracle software must be evaluated and patched against newly found vulnerabilities
Security faults with software applications and operating systems are discovered daily. Vendors are constantly updating and patching their products to address newly discovered security vulnerabilities. Organizations (including any contractor to the organization) are required to promptly install security-relevant software updates (e.g., patches, service packs, and hot fixes). Flaws discovered during security assessments, continuous monitoring, incident response activities, or information system error handling, must also be addressed expeditiously…
Unsupported software versions are not patched by vendors to address newly discovered security versions. An unpatched version is vulnerable to attack.Oracle Database 12c Security Technical Implementation Guide :: Release: 16 Benchmark Date: 24 Jan 2020
This one seems pretty straight forward, but I have run across a common misconception a few times over the years that I’d like to point out for clarity: the idea that as long as you have installed the latest available patch set for an Oracle version that you are therefore STIG-compliant, even if Oracle is no longer releasing new patches for that version. Based on over two decades of experience with DISA and the U.S. Air Force, writing STIG content, participating in multiple system evaluations for compliance, and working both for and closely with Information Assurance, I can state categorically that this is NOT TRUE. I have seen systems shutdown over this.
The correct interpretation of this STIG control is that only fully supported versions of Oracle may be deployed, and all quarterly patch sets must be installed, without exception.
As a DBA, this means that you must be aware of both the version support lifecycle and the patch set release schedule. Deployment of patches takes planning and likely some sort of configuration management process. Planning an upgrade to stay compliant may require a lot more, depending on the complexity and scale of your environment. You need to plan ahead and make sure management understands the implications, especially of upgrade. Depending on your environment, an upgrade could require any or all of the following:
- New servers (physical or virtual), if existing servers do not have the capacity to upgrade in place or the system cannot tolerate the associated downtime.
- Data migration from the old database to the new database.
- Extended downtime.
- Upgrade and testing of user applications, to make sure they support the new version of Oracle.
- Testing of the upgraded version of the database for performance, backup and recovery features, the data migration, new integrated features or capabilities, and security (new version means new STIG review).
In the DOD world I have personally overseen major upgrades which took as long as 18 months to plan and execute all of these steps in development, test, and production environments. Be sure to give yourself plenty of lead time to get through the process, especially if prerequisite steps like upgrading user applications are dependent on other people to complete.
The Oracle Lifetime Support Policy for Technology Products Guide contains information on support expiration dates for Oracle database and several other products. At the time of writing, there are several Oracle versions that are on the verge of losing support.
|Version||Premier / Extended Support Expiration|
|11.2 EE||December 2020|
|12.1 EE||July 2022|
|184.108.40.206 EE||November 2020|
|18c EE||June 2021|
|19c EE||March 2026|
If a version gets to end-of-life, beyond extended support and into the place where new security patches are no longer available, then it must be upgraded immediately to remain STIG-compliant or shutdown. Note that by the end of 2020, both 11.2 and 12.2 will no longer be supported and receiving patches, and 18c will lose support six months later. While 12.1 has been granted a short stay of execution, the fact remains that the only current version of Oracle with long-term support availability is 19c, so if you are required to be STIG compliant and aren’t running 19c yet, you should have a plan to get there as soon as possible.
Assuming that you are running a supported version of Oracle Enterprise Edition (only EE is STIG-compliant), you can check the patch history with this query:
select patch_id, version, action, status, description
When the Quarterly CPU is released, check the CPU Notice and note the specific patch number for the system…
If the currently installed patch levels are lower than the latest, this is a finding.Oracle Database 12c Security Technical Implementation Guide :: Release: 16 Benchmark Date: 24 Jan 2020
Information on available patch set updates can be found here: https://www.oracle.com/security-alerts/.
Patch bundles are released quarterly on the Tuesday closest to the 17th day of January, April, July, and October each year. Depending on your particular database environment (I’m not considering additional Oracle products, like WebLogic or user-facing applications, which might also require patching), the following Oracle product patch sets may be required:
- Oracle Database – the actual database software.
- Oracle Java Virtual Machine (OJVM) – the JVM that exists inside the database for Java stored procedures.
- Oracle JDK – the JDK that exists in $ORACLE_HOME/jdk, which supports configuration tools like asmca, dbca, and netca, is patched separately from the database software.
- Oracle Grid Infrastructure – supports Automated Storage Management, ASM Clustered File System, Clustering, and network services in a clustered environment.
None of these patches are optional from a STIG perspective. In past years it was common to delay the installation of patches or upgrades for the sake of maintaining system stability. It today’s world, that “if it ain’t broke, don’t patch it” mentality is downright dangerous. Where STIG compliance is mandatory, it is typical for security patch application to be required by Information Assurance organizations within 10-14 days after release.
While not as glamorous as real-time performance tuning or troubleshooting, making sure that your database software is up to date and patched for all known vulnerabilities is critical to the protection of your system and data. Always be aware of the support life cycle of whatever version of Oracle you are using, when patches are required to be installed by your organization, and when it will be time to be proactive and approach management about the need for upgrade.