2. S308296 Abstract (hidden slide) The Critical Patch Update is Oracle's primary mechanism for releasing security patches and informing customers about security vulnerabilities in Oracle products. This session provides an overview of the Critical Patch Update and offers recommendations to organizations to help them deal with interpreting the CPU documentation and test and deploy CPUs. It also discusses some of the enhancements brought into the CPU program last year.

3. Critical Patch Update: a year in review Bruce Lowenthal – Director Oracle Security Alerts Group Eric Maurice – Director Oracle Software Security Assurance

4. The following 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.

5. Agenda Introduction to Oracle Software Security Assurance Critical Patch Update: program overview Milestones and recent enhancements CPU tips & techniques Conclusion & questions

6. Oracle Software Security Assurance Definition and Main Components Security innovations (new security features) Secure Coding Standards Security training for developers Critical Patch Update Automated security testing Penetration testing Security documentation & best practices “Secure by Default” initiatives Independent Security Evaluations (CC, FIPS) Compliance with security checklist prior to products releases Engagement with customers, partners, and security researchers Security Customer Advisory Council (SCAC) Etc. All the processes, procedures, and technologies that have been implemented to ensure that Oracle’s products are meeting our customers’ security requirements, while providing for the most cost-effective ownership experience, including:

7. Oracle Software Security Model Oracle has adopted a lifecycle approach for security for ALL its products Security requirements are expressed (and validated) throughout all phases of the product lifecycle: – Functional specifications – Design specifications – Test specifications Security program include training requirements – Compliance with training requirements is recorded in the HR system – Relevant training throughout Product Development Product Definition Ongoing Assurance Secure Coding Standards

8. Oracle’s Vulnerability Remediation Practices Maintaining the security posture of Oracle customers While Oracle tries to prevent as much as possible the introduction of security vulnerabilities in its software, vulnerabilities make their way into released code: – Errors made by developers resulting in undesirable security behavior(s) – Unexpected use of software resulting in security complications – Vulnerabilities resulting from new attack methods, tools, or combinations thereof – Etc.  Importance of Ongoing Assurance

9. Critical Patch Update (CPU) Predictable – CPUs are released every quarter – Schedule announced a year ahead of time Transparent – ALL customers are treated equally – Vulnerabilities fixed in severity order – Remediation policies are posted online (http://www.oracle.com/technology/deploy/security/securityfixli fecycle.html)http://www.oracle.com/technology/deploy/security/securityfixli fecycle.html Effective – CPU patches are thoroughly tested – CPU documentation provides detailed information about the severity of the vulnerabilities, impacted components, etc.

10. Critical Patch Update (CPU) Predictable – CPUs are released every quarter – Schedule announced a year ahead of time – (CPUOct2009 was postponed a week because of OpenWorld) Transparent – ALL customers are treated equally – Vulnerabilities fixed in severity order – Remediation policies are posted online (http://www.oracle.com/technology/deploy/security/securityfixlifecycl e.html)http://www.oracle.com/technology/deploy/security/securityfixlifecycl e.html Effective – CPU patches are thoroughly tested – CPU documentation provides detailed information about the severity of the vulnerabilities, impacted components, etc. Maintaining your security posture at the lowest possible cost

11. Security Alerts Oracle retains the capability to issue workaround instructions or security patches in case of critical vulnerabilities (highly exploitable and publicly known vulnerabilities, 0-day, etc.) – Since the introduction of the Critical Patch Update program in January 2005, only one Security Alert has been issued (to address a flaw in BEA WebLogic plugin for Apache in August 2008) Directions on how to subscribe to Oracle security notifications are available at : http://www.oracle.com/technology/deploy/security/sec urityemail.html http://www.oracle.com/technology/deploy/security/sec urityemail.html

12. The Critical Patch Update (2005-2009) Despite inclusion of new product lines (BEA, x10, Siebel, Hyperion, etc.) the size of the CPU remains about constant.

13. Recent Milestones & Enhancements New products added to the CPU program Oracle Secure Backup BI Publisher Oracle Communications Business Unit Products Oracle BEA JRockit - Conversion of BEA support systems to Oracle’s Oracle BPEL Process Manager Outside In Technology

14. Recent Milestones & Enhancements My Oracle Support Portal  What if you were able to quickly and accurately identify which systems needed to be patched and locate the corresponding patches?  What if you were able to periodically and automatically assess the configuration of your systems against the recommended security baselines from Oracle?

15. Recent Milestones & Enhancements My Oracle Support Portal  What if you were able to quickly and accurately identify which systems needed to be patched and locate the corresponding patches?  What if you were able to periodically and automatically assess the configuration of your systems against the recommended security baselines from Oracle? already These capabilities are already included within Oracle Premier Support

16. Recent Milestones & Enhancements My Oracle Support Portal

17. The customized portal provides a bird’s eye view of your environment. You can quickly locate systems that need to be patched.

18. Recent Milestones & Enhancements My Oracle Support Portal

19. Health Checks A number of Health Checks corresponding to the recommendations in the Security Guides are available today, for example, for Oracle Database Server:  Size of redo log >1Mb?  Use of 3 redo logs or more?  Data dictionary protection enabled?  Auditing enabled?  OS authentication disabled?  Remote OS authentication disabled?  Remote password file protected?  Etc.

20. Recent Milestones & Enhancements My Oracle Support Portal For more information: – Sessions: S308076: Resolve Issues Faster with My Oracle Support and Oracle Enterprise Manager, Thursday October 15 th at 1:30 PM S308122: Next-Generation Database Patch Automation: Get Your Life Back! Thursday October 15 th at 1:30 PM – Demos My Oracle Support, Moscone West, W-137, Demogrounds

21. Recent Milestones & Enhancements Patch Set Updates (PSUs) Enhanced patch offering introduced with CPUJul2009 PSUs are cumulative patches, including: – Security fixes – Other recommended bug fixes PSUs are available for: – Oracle Database Server 10.2.0.4 (Starting with CPUJul2009) – Oracle Database Server 11.1.0.7 (Starting with CPUOct2009) – Oracle Enterprise Manager Grid Control 10.2.0.5 (Starting in October 2009) – Starting with CPUOct2009, for some Unix platforms the PSU is available on the quarterly release date, and the CPU only update is available by request. (See Note 882604.1) – Database PSU patches are not available on Windows, but the PSU content is included in the Windows bundle patches

22. Recent Milestones & Enhancements Patch Set Updates (PSUs) PSUs include low risk/high value fixes: – Fixes only critical technical issues (wrong results, corruptions, hangs, etc.) – Fixes issues that have been encountered by large number of customers PSUs result in enhanced integrated testing of fixes that Oracle recommend PSUs result in introduction of new baseline version – The 5 th place version number indicates the PSU release level (e.g. 10.2.0.4.2) For more information: – S311534: Oracle Patching and Maintenance: A Practical Guide for System Administrators, Thursday, October 15 th at 1:30 PM

23. Recent Milestones & Enhancements Patch Set Updates (PSUs) Customers need to make a determination as to which patching mechanism they will commit (PSU vs. traditional CPU format): – The PSU and CPU released each quarter contain the same security content, HOWEVER – The patches employ different patching mechanisms A PSU can be applied on the CPU released at the same time or on an any earlier CPU for the base release version. It can also be applied on any earlier PSU or the base release version. CPUs are only created on the base release version to which they apply: – Once a PSU has been installed, the only way to get future security content is to apply subsequent PSUs. For more information, see Note 854428.1

24. CPU Tips & Techniques Preparing for the CPU Pre-release notice is posted on the Thursday before the release of the CPU. It lists: – Affected product families and versions – Maximum CVSS score – Etc. It is posted on the Critical Patch Updates & Security Alerts page at http://www.oracle.com/technology/deploy/security/alerts.htm

25. CPU Tips & Techniques Assessing the severity of the vulnerabilities fixed by the CPU CPU documentation should be your primary source for Oracle vulnerability information The risk matrices are designed to: – Provide as much information as possible so that customers can assess the severity of the vulnerabilities, determine whether patching is required or not, and identify areas that need to be tested… – Without necessarily further empowering malicious attackers who use any technical information (and the patches themselves) to develop malicious tools and exploit methods

26. CPU Tips & Techniques Assessing the severity of the vulnerabilities fixed by the CPU “CVE#” – Unique identifier for the vulnerability – Since CPUJul2008, Oracle has replaced its proprietary numbering scheme with Common Vulnerabilities & Exposures (CVE) identifiers (Oracle is a Candidate Naming Authority under the CVE Program). – Format of the identifiers is YYYY-sequential number – Note: Use of italics denote that vulnerability affects other components (i.e. the vulnerability will be listed in at least one other risk matrix in the CPU documentation) “Component” – List the product component that is affected – Note: Your organization is not exposed to the vulnerability if it is not using the affected component (and/or it has not been installed or enabled)

27. CPU Tips & Techniques Assessing the severity of the vulnerabilities fixed by the CPU “Protocol” – List the protocol that is required to exploit the vulnerability – Typical values include: Oracle Net, Local, HTTP, Network, etc. – Note: It is generally possible to mitigate a vulnerability by limiting access or controlling use of the affected protocol “Package and/or Privilege Required” – List the packages, privileges, roles, responsibilities or other preconditions required to attempt to exploit the vulnerability – Typical values include: None, Valid Session, Create Table, Etc. – Note: It may be possible to reduce risk by controlling access to the package or limiting number of people/resources with affected privileges. For example, by revoking untrusted users’ access to affected packages. HOWEVER, ALWAYS make sure to check these changes in test environment FIRST!

28. CPU Tips & Techniques Assessing the severity of the vulnerabilities fixed by the CPU “Remotely Exploitable without Authentication” – Indicate whether the vulnerability may be remotely exploitable by a malicious user who does NOT have authentication credentials for the targeted system – Possible values are: Yes No – Note: While many customers focus their attention on this value (“Yes”), it is extremely important to understand the other aspects of the vulnerability, particularly the CVSS 2.0 Access Vector, Access Complexity, and Authentication attributes

29. CPU Tips & Techniques Assessing the severity of the vulnerabilities fixed by the CPU CVSS 2.0 “Base Score” – Oracle only provides the CVSS Base Score (Not the Temporal or Environmental scores which may be computed by customers) – The Base Score provides an indication of the relative severity of the vulnerability – Value ranges from 0.0 (vulnerability cannot be directly exploited in default configuration) to 10.0 (vulnerability can result in full compromise of the system down to the OS layer – Impact values reported as “Complete”) – A score of 7.5 typically indicate a full compromise of the database (for Database Server), with no consequences at the OS layer. This is because the standard requires Oracle to use the value of “Partial” for the Impact values) when no OS compromise is possible

30. CPU Tips & Techniques Assessing the severity of the vulnerabilities fixed by the CPU CVSS 2.0 “Access Vector” – This value reflects how the vulnerability can be exploited – Possible values are: Local: requires physical access to or local shell account with the targeted system Adjacent Network: requires the attacker to have access to either the broadcast or collision domain of the targeted system (e.g. local IP subnet, Bluetooth, Wireless, etc.) Network: requires only network access (i.e. the vulnerability is bound to the network stack and the attacker does not require local network access or local access) – Note: Proper network access controls can help prevent the exploitation of many Oracle vulnerabilities. For example, it is NOT a recommended practice to leave sensitive Database Servers exposed to the Internet. When ports need to remain open to the Internet, the use of Reverse Proxies can effectively hide sensitive ports from malicious attackers.

31. CPU Tips & Techniques Assessing the severity of the vulnerabilities fixed by the CPU CVSS 2.0 “Access Complexity” – Denotes the complexity of launching a successful exploit once the exploit code has been implemented – Possible values are: High: Requires specialized access conditions (e.g. need for elevated privileges or access to sensitive information (social engineering), requirement to spoof other systems, etc. or the vulnerable configuration is seen very rarely in practice) Medium: Requires somewhat specialized access conditions (e.g. the attacker must be part of a group of systems or users with some level of authorization, specialized information must be obtained before the attack, or the affected configuration is non- default, and is not commonly configured Low: No need for specialized access conditions or extenuating circumstances (e.g. anyone on the Internet can attempt to exploit the vulnerability, the affected configuration is “by default” or very common, etc.)

32. CPU Tips & Techniques Assessing the severity of the vulnerabilities fixed by the CPU CVSS 2.0 “Authentication” – Indicates the number of times an attacker must authenticate to the target systems in order to exploit the a vulnerability – Note: This value does NOT measure the strength or complexity of the authentication process. It only indicates that an attacker is required to provide credentials before attempting to exploit the vulnerability. – Possible values are: Multiple: The attacker needs to authenticate two or more times, even if the same credentials are used each time. Single: The attacker needs to be logged into the system (command line, desktop session or web interface). None: The attacker doesn’t need to be authenticated to the targeted system.

33. CPU Tips & Techniques Assessing the severity of the vulnerabilities fixed by the CPU CVSS 2.0 “Confidentiality, Integrity, Availability” – Denotes the confidentiality, integrity, and availability impacts of a successfully exploited vulnerability (i.e. “How much in trouble can you be?”) – Possible values are: Complete: There is a total compromise of the system. – Confidentiality: All system files are being revealed. The attacker is able to read all of the system's data (memory, files, etc.) – Integrity: The entire system is being compromised. The attacker is able to modify any files on the target system. – Availability: A total shutdown of the affected system is possible. The attacker can render the resource completely unavailable. Partial +: This is a CUSTOM rating by Oracle which maps to the “Wide” value used prior to the adoption of CVSS. This rating is used when the exploit affects a wide range of resources, e.g. all database tables. Note: The use of this custom rating doesn’t change the CVSS Base Score reported by Oracle. Partial: Anything in between “None” and “Complete” (i.e. the vulnerability will affect controls over a number of files, resources, records, etc. or there is limited service interruption). None: No impact to the system

34. CPU Tips & Techniques Assessing the severity of the vulnerabilities fixed by the CPU Last Affected Patch Set (per Supported Release) – Product versions that do not have a patch set listed in this entry do not have the vulnerability in any supported patch set – Product versions that do have a patch set listed in this entry are subject to the vulnerability described in this row except for patch sets, if they exist, that follow the patch set specified in this entry. For example, if "10.2.0.4" is listed then Database Version 10g version 2 contains the vulnerability in all supported patch set versions 10.2.0.4 and before. However patch sets 10.2.0.5 and later do not have the vulnerability. Database versions 9i R2, 10g and 11g would not have the vulnerability in any supported patch set version since no patch set for those versions was specified. Notes – Refers to additional information listed below the risk matrix. For example, the notes will list whether the vulnerability affects client-only installations. In some instances, the notes will indicate that the reported CVSS Base Score is only applicable to a certain platform (Oracle reports the highest CVSS score regardless of the affected platform, and it is not uncommon to have different CVSS Base Scores for Windows, Unix, and Linux platforms).

35. CPU Tips & Techniques Patching, not patching, delaying decisions Is the affected component installed/enabled in my environment? Yes: Patching may be required. Am I running an affected version? Yes: Is the risk created by the vulnerability acceptable in my environment without taking additional mitigation measures? Yes: Make sure to document the risk and monitor external mitigation measures so as to initiate patching if mitigation controls are removed. No: Can I implement additional mitigation measures so as to prevent the exploitation of the vulnerability (controls over the protocol required or removal of package or privilege required by the vulnerability? Yes: If implementation of additional mitigation measures is more compelling than patching, then the organization should implement such controls and document them so as to periodically reassess its security posture (after new CPU, or when changes are made to the environment) No: Plan for application of the Critical Patch Update as soon as possible No: Vulnerability may not be relevant to my organization. Oracle recommends that CPUs be applied as soon as possible. However systematic application of all CPUs may be prevented by other organizational requirements

36. Conclusion CPU program is designed to be predictable and effective: – Organizations need to develop policies and procedures to Save cost by developing repeatable patching procedures Maintain a proper security posture by making educated patching decisions – CPUs are an evidence of Oracle’s commitment to Ongoing Security Assurance Oracle continues to look at ways to “ease the burden” of patching – Options in Oracle Enterprise Manager – My Oracle Support Portal – Information sharing (technical white papers, etc.)

37. For More Information search.oracle.com or http://www.oracle.com/technology/deploy/security/alerts.htm