1 / 37

Critical Patch Update: a year in review

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

theola
Download Presentation

Critical Patch Update: a year in review

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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.

  3. Agenda <Insert Picture Here> • Introduction to Oracle Software Security Assurance • Critical Patch Update: program overview • Milestones and recent enhancements • CPU tips & techniques • Conclusion & questions

  4. 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. Oracle Software Security AssuranceDefinition and Main Components 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:

  5. SecureCodingStandards 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 ProductDefinition OngoingAssurance Product Development

  6. Oracle’s Vulnerability Remediation PracticesMaintaining 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

  7. 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/securityfixlifecycle.html) • Effective • CPU patches are thoroughly tested • CPU documentation provides detailed information about the severity of the vulnerabilities, impacted components, etc.

  8. 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/securityfixlifecycle.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

  9. 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/securityemail.html

  10. 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.

  11. Recent Milestones & EnhancementsNew 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

  12. Recent Milestones & EnhancementsMy 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?

  13. Recent Milestones & EnhancementsMy 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? These capabilities are already included within Oracle Premier Support

  14. Recent Milestones & EnhancementsMy Oracle Support Portal

  15. Recent Milestones & EnhancementsMy Oracle Support Portal You can quickly locate systems that need to be patched. The customized portal provides a bird’s eye view of your environment.

  16. Recent Milestones & EnhancementsMy Oracle Support Portal

  17. Recent Milestones & EnhancementsMy Oracle Support Portal • 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.

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

  19. Recent Milestones & EnhancementsPatch 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

  20. Recent Milestones & EnhancementsPatch 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 5th 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 15th at 1:30 PM

  21. Recent Milestones & EnhancementsPatch 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

  22. CPU Tips & TechniquesPreparing 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

  23. CPU Tips & TechniquesAssessing 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

  24. CPU Tips & TechniquesAssessing 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)

  25. CPU Tips & TechniquesAssessing 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!

  26. CPU Tips & TechniquesAssessing 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

  27. CPU Tips & TechniquesAssessing 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

  28. CPU Tips & TechniquesAssessing 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.

  29. CPU Tips & TechniquesAssessing 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.)

  30. CPU Tips & TechniquesAssessing 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.

  31. CPU Tips & TechniquesAssessing 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

  32. CPU Tips & TechniquesAssessing 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).

  33. CPU Tips & TechniquesPatching, not patching, delaying decisions Oracle recommends that CPUs be applied as soon as possible. However systematic application of all CPUs may be prevented by other organizational requirements

  34. 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.)

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

More Related