Oracle Database Critical Patch Update (CPU) Planning for 2016

Oracle Database, Oracle Critical Patch Updates

With the start of the new year, it is now time to think about Oracle Critical Patch Updates for 2016. Oracle releases security patches in the form of Critical Patch Updates (CPU) each quarter (January, April, July, and October). These patches include important fixes for security vulnerabilities in the Oracle Database. The CPUs are only available for certain versions of the Oracle Database, therefore, advanced planning is required to ensure supported versions are being used and potentially mitigating controls may be required when the CPUs can not be applied in a timely manner.

CPU Supported Database Versions

As of the October 2015 CPU, the only CPU supported database versions are 11.2.0.4, 12.1.0.1, and 12.1.0.2. The final CPU for 12.1.0.1 will be July 2016. 11.2.0.4 will be supported until October 2020 and 12.1.0.2 will be supported until July 2021.

11.1.0.7 and 11.2.0.3 CPU support ended as of July 2015.

Database CPU Recommendations

When possible, all Oracle databases should be upgraded to 11.2.0.4 or 12.1.0.2. This will ensure CPUs can be applied through at least October 2020.
[12.1.0.1] New databases or application/database upgrade projects currently testing 12.1.0.1 should immediately look to implement 12.1.0.2 instead of 12.1.0.1, even if this will require additional effort or testing. With the final CPU for 12.1.0.1 being July 2016, unless a project is implementing in January or February 2016, we believe it is imperative to move to 12.1.0.2 to ensure long-term CPU support.
[11.2.0.3 and prior] If a database can not be upgraded, the only effective mitigating control for many database security vulnerabilities is to strictly limit direct database access. In order to restrict database access, Integrigy recommends using valid node checking, Oracle Connection Manager, network restrictions and firewall rules, and/or terminal servers and bastion hosts. Direct database access is required to exploit database security vulnerabilities and most often a valid database session is required.

Regardless if security patches are regularly applied or not, general database hardening such as changing database passwords, optimizing initialization parameters, and enabling auditing should be done for all Oracle databases.