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 18.104.22.168, 22.214.171.124, and 126.96.36.199. The final CPU for 188.8.131.52 will be July 2016. 184.108.40.206 will be supported until October 2020 and 220.127.116.11 will be supported until July 2021.
18.104.22.168 and 22.214.171.124 CPU support ended as of July 2015.
Database CPU Recommendations
- When possible, all Oracle databases should be upgraded to 126.96.36.199 or 188.8.131.52. This will ensure CPUs can be applied through at least October 2020.
- [184.108.40.206] New databases or application/database upgrade projects currently testing 220.127.116.11 should immediately look to implement 18.104.22.168 instead of 22.214.171.124, even if this will require additional effort or testing. With the final CPU for 126.96.36.199 being July 2016, unless a project is implementing in January or February 2016, we believe it is imperative to move to 188.8.131.52 to ensure long-term CPU support.
- [184.108.40.206 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.