2. The Security Benefit of Oracle Premier Support
Bruce Lowenthal
Senior Director, Security Alerts Group
Oracle
October 25, 2018

3. Safe Harbor Statement
The preceding is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.

4. What is Oracle Software Security Assurance?
Encompassing every phase of the product development lifecycle, Oracle Software Security Assurance (OSSA) is Oracle's methodology for building security into the design, build, testing, and maintenance of its products. Oracle's goal is to ensure that Oracle's products, as well as the customer systems that leverage those products, remain as secure as possible
OSSA programs include:
Critical Patch Update and Security Alert Programs
“Secure by default” initiative
Secure Coding Standards
Security certifications (Common Criteria and FIPS)
Ethical hacking
OSSA applies to:
Oracle on-premises products
Oracle cloud products and services
So, what is Oracle Software Security Assurance (OSSA)?
OSSA is the generic term to coin the various activities, programs, and policies that help making sure that Oracle-developed code is as secure as possible. Wikipedia provides a great definition of Security Assurance: “Software security assurance is a process that helps design and implement software that protects the data and resources contained in and controlled by that software.“
You may be aware of OSSA through a number of programs such as the Critical Patch Update (CPU) and Security Alert programs. The Critical Patch Update (CPU) and Security Alert programs are Oracle’s vulnerability fixing programs. You may not be aware that other OSSA programs include the “secure by default” initiative which has resulted in providing over time better default configuration for Oracle products. The Oracle Secure Coding Standards are Oracle’s formal standards for helping developers avoid common security flaws. Oracle also maintains a team of dedicated ethical hackers.

5. What is ongoing security assurance?
The primary objective:
To help ensure that security controls provided by software are effective, work in a predictable fashion, and are appropriate for that software and
To ensure this objective continues to be met throughout the life of software
As part of its commitment to ongoing assurance,
Oracle periodically releases security fixes against released and supported versions of its products and services
Continuously introduces security enhancements in new versions of its products and services including key “security in depth” enhancements

6. Why does Oracle release security fixes?
To address security defects (vulnerabilities) in Oracle code discovered internally or reported by security researchers
To address security vulnerabilities in 3rd party components embedded in Oracle product distributions such as Heartbleed fixes for OpenSSL
To maintain a product’s security posture (e.g., replacement of obsolete cryptography with stronger versions)
To address new classes of vulnerabilities such ase Spectre or Java Deserialization
To improve “security in depth” reducing impact of “blended attacks”
So why does Oracle periodically release security fixes?
Through various OSSA activities, Oracle tries to prevent the introduction of security flaws in newly-released code. For example, the Secure Coding Standards are intended to help developers avoid common security mistakes. Oracle make wide sure of security testing tools ranging from static code analysis tools to provide periodic feedback to developers on how well they are doing, to fuzzing tools which look for resilience against unintended inputs… However, security bugs make their way onto complex software. And one reason for releasing fixes is to address these flaws when they’re discovered.
Oracle, as does all large software vendors, make use of third-party components. Oracle will pass through fixes for these third-party components when they have been successfully tested.
Oracle also has to release fixes or updates to do away with aging or obsolete components. For example, crypto components have a finite life.
Oracle also issues security updates to address new attack methods, or new class of vulnerabilities, or to provide defense-in-depth protection, particularly as customers alter how they use Oracle software.

7. The Affect of 3rd Party Components
In the past after a product was in production for years by a customer
There was little call to apply fixes as customers could confirm proper operation
BUT: Security fix distributions changed this model
Successful exploits occur long after applications are in “steady-state” productions e.g. UK Health Care successful ransomeware attacks
Included 3rd party components aggravate this situation
Large software products contain hundreds of 3rd party components
Hackers focus on 3rd party components leveraging exploits across many products
Many successful attacks against vulnerabilities fixed many months or years earlier e.g. Cryptocoin mining attacks, SF Muni attacks
Oracle issues about 400 fixes a year for 3rd party component vulnerabilities
So why does Oracle periodically release security fixes?
Through various OSSA activities, Oracle tries to prevent the introduction of security flaws in newly-released code. For example, the Secure Coding Standards are intended to help developers avoid common security mistakes. Oracle make wide sure of security testing tools ranging from static code analysis tools to provide periodic feedback to developers on how well they are doing, to fuzzing tools which look for resilience against unintended inputs… However, security bugs make their way onto complex software. And one reason for releasing fixes is to address these flaws when they’re discovered.
Oracle, as does all large software vendors, make use of third-party components. Oracle will pass through fixes for these third-party components when they have been successfully tested.
Oracle also has to release fixes or updates to do away with aging or obsolete components. For example, crypto components have a finite life.
Oracle also issues security updates to address new attack methods, or new class of vulnerabilities, or to provide defense-in-depth protection, particularly as customers alter how they use Oracle software.

8. How does Oracle release security fixes?
Critical Patch Updates are released quarterly (for all Oracle on-premises products) on a predictable schedule published a year in advance
Off-cycle Security Alert Advisories are released for high-risk vulnerabilities
About twice per year
Oracle fixes highest security bugs first
Security bugs are tested across the stack to prevent regression issues
Critical Patch Update and Security Alert fixes are only provided for product versions that are “covered under the Premier Support or Extended Support phases of the Lifetime Support Policy.”

9. How “critical” are the fixes in the Critical Patch Update?
‘C’ in CPU stands for CRITICAL
Severe vulnerabilities including published and researcher-reported vulnerabilities
Many of these bugs, if successfully exploited, can result in serious compromise for the affected Oracle system(s)
Oracle continues to receive reports of successful exploitation of vulnerabilities for which Oracle has already released fixes.
The Critical Patch Update is Oracle’s primary program for backporting security fixes in actively-supported product versions. The “C” in CPU, stands for Critical. This is because Oracle determine that an active exploitation of these bugs can create significant risk for customers. Oracle always recommends that CPUs be applied as quickly as possible. Unfortunately, Oracle continues to receive periodic reports of security incidents that have resulted from the successful exploitation of security bugs for which fixes were available. As we will see later in this presentation, it is particularly important to keep up with security releases because the non application of security fixes can lead to a degradation over time of your security posture.

10. Can you do away with Oracle security fixes?
Can a firewall (or other mitigation measures) protect you?
Not if you want to be secure
Locking one door of your car does not make it secure
Historically, Oracle has found that mitigation published by non-Oracle sources (other than "apply the patch“) has often been ineffective or has caused adverse side effects leading to application failures which can occur months after the non-Oracle mitigation has been applied
Security companies (vendors of firewall, IDS, IPS, etc.)
Do not get “special” information from Oracle.
Don’t have information and technical ability to detect and prevent exploits against all Oracle vulnerabilities
So, do you really need to apply the CPU patches? After all, does your corporate firewalls and other security systems provide some sort of mitigation against these issues?
The short answer is that you absolutely need to make sure to keep up with security fixes. You need to assess the risk posed by security bugs and prioritize your security patching effort accordingly. In doing so, you need to keep the following things in mind:
You will face generally a greater risk If a bug is remotely exploitable without authentication, and the affected interface is exposed on the Internet.
You should rely on Oracle documentation to assess the severity of Oracle bugs and whether you can do away with fixes. This is because in many instances (if not most instances), Oracle has found that security information provided by third-party is inaccurate. Even worse, in most instances, Oracle has found that mitigation recommendations provided incomplete mitigation and often would cause serious consequences.
Finally, keep in mind that security companies do not get more information than you do about Oracle security bugs. In many instances, it is very hard to develop model for abnormal behavior or suspicious patterns across the various interfaces and protocols used by Oracle products.
Keeping up with security releases is the only way your organization can effectively maintain its security in depth posture.

11. Can you do away with Oracle security fixes?
Can you afford to have your security posture degrade over time?
CPU fixes are being reverse-engineered by malicious actors
To identify the nature of the bug and how to exploit it
To develop weaponized version of the exploit (e.g., Metasploit)
This is because malicious actors (and security auditors) know that many customers will not apply security patches in a timely fashion
This also means that malicious actors are further empowered after the release of each Critical Patch Update to carry attacks against customers who do not apply the Critical Patch Update
As previously stated, the non-application of security fixes results in a significant degradation of your security posture over time. This is due to a combination of reasons.
Security fixes are being reverse-engineered by malicious actors, and the knowledge they derive is used to produce weaponized exploit. The use of these exploits is further facilitated by common hacking frameworks such as Metasploit.
In effect, the release of a fix, catch the attention of malicious actors, who know that some organizations will fail to apply the security fix. In the case of particularly severe vulnerabilities, the malicious actors will consider it a race to produce a malicious payload prior to the application of the patch by his intended target.
While customers are empowered to improve their security posture, this empowerment only takes place if the patches are applied.

12. Can you do away with Oracle security fixes?
What are the business implications of running vulnerable systems?
Failure to apply security fixes severely degrades customer security (all vendors)
Over time, the degradation of the security posture of the organization accelerates:
Exploits for vulnerabilities of Oracle published fixes are increasingly included in "Hacker Exploit Kits"
Exploits impact is aggravated via blended attacks
Oracle does not determine if fixed vulnerabilities in Supported versions apply to unsupported versions
Customers should assume that unsupported product versions have nearly all the vulnerabilities in newer versions plus more (e.g. Deserialization vulnerabilities have been in software since 1997)
Good IT governance demands applying published security fixes in a timely manner
Lack of timely security patching could have statutory compliance implications and give rise to regulatory enforcement actions
To conclude this presentation, we need to briefly discuss the business impacts of not applying security fixes.
Organizations largely rely on security controls provided by software. Vulnerabilities result in the degradation of these controls. Publicly-known and left-unpatched, severe vulnerabilities can result in giving the key of your digital castle to malicious perpetrators. Would you consider operating a luxury car dealership with an alarm system that you know to be broken?
Over time, “opting out of support” means that you will lose access to fixes for critical security vulnerabilities. You may end up running unsupported versions that will not be tested by Oracle for the presence of vulnerabilities. Many of these older releases are likely to have the same kinds of bugs that are fixed by Oracle in subsequent releases. At the same time, with the release of each CPU, malicious actors will learn about more ways to break into your environment.
IT governance frameworks all consider patching an importance piece of IT governance. This is good a good reason. Most incidents do not result from the exploitation of “exotic” 0-day bugs, but from human errors (users tricked through phishing attacks or systems misconfigurations, or excessive privileges) and the exploitation of known vulnerabilities left open due to the lack of patching.
It is also important to remember that, in addition to the brand damages and the public embarrassment associated with an attack, the lack of timely security patching could have statutory compliance implications and give rise to regulatory enforcement actions. Can you really afford it?

13. What should you do? Apply Oracle published security fixes quickly
Critical Patch Updates and Security Alerts
Subscribe to Oracle’s security notifications
Stay on supported releases
Later releases provide and enhanced security posture
Follow Oracle’s security guidelines, especially for product deployments
Assess the security assurance practices of your vendors
And leverage the programs that are relevant to you!
So, what can you do?
You need to keep up with security releases. You need to look at the Oracle security advisories to accurately assess the risks posed by the vulnerabilities that are fixed by Oracle. Remember that Critical Patch Updates are released on a fixed schedule (the Tuesday closest to the 17th of the months of January, April, July, and October). Pay particular attention to the Security Alerts. These are for particularly bad bugs, that justify the release of an out of band patch. You can subscribe to Oracle’s security notifications to make sure that you don’t miss on any of these fixes.
You need to stay on actively-supported releases to get security fixes. Keep in mind that newer releases benefit from security-in-depth fixes and other security improvements. Always make sure to deploy your products in accordance with the security documentation.
Finally, and more generally, continue to assess the security assurance practices of your suppliers. Make sure that they have formal secure coding standards, and that they have effective security vulnerability remediation programs (such as the CPU) in place. But assessing these programs is not enough! You need to leverage these programs, for example by taking advantage of the security fixes provided by your vendors.

14. For more information Oracle Software Security Assurance web site
Security Alerts and Critical Patch Updates
Lifetime Support Policy

15. Questions