Your Federal Quarterly Tax Payments are due April 15th Get Help Now >>

Security Patching Practices by Oracle Customers by rhd66230

VIEWS: 7 PAGES: 10

									Security Patching Practices by Oracle Customers


 A joint survey by the Independent Oracle User Group and Oracle




                          February 25, 2009
                                                             2



Objectives
In October 2007, the Independent Oracle User Group became a member of the Oracle Security
Customer Advisory Council for the purpose of providing feedback to Oracle on behalf of its member
base. The mission of the Security Customer Advisory Council is to provide feedback on the security
roadmaps for Oracle products, as well as advise Oracle as it relates to various Oracle Software Security
Assurance activities, including the Critical Patch Update, Oracle’s primary mechanism for the issuance
of security bug fixes. Under the Critical Patch Update process, security bug fixes for all Oracle
products are released on the same day every quarter (on the Tuesday closest to the 15th of the months
of January, April, July, and October).

The Critical Patch Update1 arguably represents the most visible program of Oracle Software Security
Assurance. Security vulnerabilities may negatively impact the security posture of organizations using
the affected systems in production. Furthermore, the cost and effort associated with periodically
patching production environments are not negligible. While Oracle has put in place extensive
programs and procedures throughout development to prevent the introduction of significant security
vulnerabilities in its products, it is impossible for any software vendor to fully and permanently prevent
all security vulnerabilities because of the complexity of enterprise software and the changing threat
landscape experienced in the “real world” (introduction of new attack vector, evolution of hacking
tools, etc.). Therefore, organizations must take steps to efficiently deal with vendor-issued security
patches, and aim to apply relevant security patches as soon as possible in order to retain a satisfactory
security posture.

The goal of this survey was threefold:
       Understand the current practices of organizations as they relate to Oracle’s Critical Patch
           Update;
           Identify the challenges faced by organizations in regards to the timely application of
            security patches; and
           Attempt to identify specific recommendations to present to Oracle in order to further
            increase the effectiveness of the Critical Patch Update process or other Oracle Software
            Security Assurance activities.




1
    For more information, see http://www.oracle.com/technology/deploy/security/alerts.htm
                                                    3




Methodology
Two online surveys were conducted between May and August 2008. The online surveys were hosted
on the IOUG web servers. The questionnaire was jointly developed by Oracle Global Product Security
and IOUG representatives. This report was also written jointly by the Global Product Security and the
IOUG teams. Over 150 individual surveys were completed from as many different organizations. The
questionnaire was designed to get feedback from those individuals whose job functions imply the
application of Critical Patch Updates and Patch Sets.

In order to validate the feedback received in the surveys, the question was asked of the respondents, if
the application of Critical Patch Update and Patch Sets was part of their function because, in most
organizations, the job of testing and deploying Critical Patch Updates and Patch Sets does not fall
within the responsibilities of systems or database administrators.

      Figure 1: Role of respondents as it relates to the Critical Patch Update in their organization
       (multiple answers were allowed – percentage as of total number of responses received)
                                                   4




Findings
1) Respondents report that few organizations have policies mandating the
   application of Critical Patch Updates

The survey found that a small percentage of organizations in this survey (26%) require that Critical
Patch Updates be applied systematically across the entire environment when they are released by
Oracle.

On the other hand, almost 1/5 of all respondents (19%) report that their organizations do not have
specific requirements for the application of any vendor supplied security patches. This means that
these organizations do not have formal policies related to security patching as typically recommended
by IT governance frameworks such as COBIT or ISO 27001. Additionally, 11% of the respondents
report that their policies do not extend to Oracle patches. This means that roughly one third of the
respondents (30%) do not have policies in regards to Critical Path Updates from Oracle.

A large proportion of respondents (36%) have reported that their organizations require that the
application of the Oracle security patches be justified. In such instances, not surprisingly, respondent
report that their organizations seem to favor a risk analysis as opposed to a cost/benefit analysis in
order to justify patching their production environment. Furthermore, a small number of respondents
(6%) have reported that the systematic application of Oracle Critical Patch Updates are limited to
mission-critical systems.

Figure 2: What is your organization’s specified policy in regards to Critical Patch Updates?
                                                  5



The surveys also provided the respondent to input “free form” comments. The comments entered by
respondents in this area of the survey seem to indicate that systematic patching is mandated in most
organizations only for Microsoft environment as it is considered most at risk or vulnerable.

These findings highlight the organizational differences between organizations as it relates to patching
policies. Many organizations do not have specific policies extending to Oracle Critical Patch Updates.
However, when organizations have policies applicable to Critical Patch Updates, the predominant
practice seems to require that Critical Patch Update application be justified or limited to mission-
critical environments.

2) Most respondents report that their organizations are either current with
   the Critical Patch Update or one release late

When asked how quickly they apply Critical Patch Update, thirty percent (30%) of the respondents
indicated that they typically apply Critical Patch Updates before the next one is released. Twenty-five
percent (25%) of the respondents indicated that they were typically one Critical Patch Update cycle
late (three to six months). Ten percent (10%) of the respondents indicated that they were typically two
Critical Patch Update cycles late (six to nine months). Eight percent (8%) of the respondents indicated
that they were three Critical Patch Update cycles late (nine to twelve months). Another eight percent
(8%) of the respondents indicated that they were four or more Critical Patch Update cycles late (more
than twelve months late). Eleven percent (11%) of the respondents indicated that they never applied
Critical Patch Updates. Eight percent (8%) of the respondents indicated they didn’t know (or were
unwilling to answer the question).

 Figure 1: How quickly do you apply Critical Patch Updates?
                                                   6



Responses to this question appear consistent with the organizational practices reported by respondents
in the previous section of the survey. While over half the respondents (55%) reported to be either
current or one Critical Patch Update cycle late in their Critical Patch Update application, the absence
of corporate mandating application of Critical Patch Updates, and the resulting requirement to justify
each Critical Patch Update application, result in a large proportion of Oracle users not being able to
stay at current security patch level.

These findings highlight the great gap that exists in practice and expectations across a typical IT
environment. On one end of the spectrum, it appears that users expect desktop environment to be
patched on a monthly basis, or even more often such as is the case with daily distribution of antivirus
signatures. However, it appears that such patching frequency cannot be maintained for enterprise
servers of business applications. It is likely that a combination of factors explain the lower frequency
at which security patching activity does occur on such systems. Such factors may include: the absence
of specific policies mandating patching, or the need to justify patching activity on these systems; the
complexity related to patching production systems otherwise expected to remain available “24*7”; the
confidence in the security posture of such systems because of additional security measures; and the
fear of breaking dependencies between databases and business applications.

3) Most respondents feel that the Critical Patch Update process
   contributes to maintaining a positive security posture

When asked to rate the Critical Patch Update program in its ability to protect their security posture,
forty-two percent (42%) of the respondents indicated that the Critical Patch Update process was
effective or extremely effective in its ability to helping them maintain a positive security posture.
Forty-five percent (45%) of the respondents indicated that the Critical Patch Update process was
somewhat effective in its ability to helping them maintain a positive security posture. Only thirteen
percent (13%) of the respondents indicated that they felt the Critical Patch Update process was
ineffective (very poor or poor) in its ability to protect their security posture.
                                                   7



 Figure 4: How would you rate Oracle’s Critical Patch Update program in its ability to protect your
 security posture?




This figure appears consistent with the number of respondents which indicated they had never
deployed a Critical Patch Update. In the absence of publicly reported security incident resulting from
the existence of an un-patched vulnerability in an Oracle system, one can only assume that the negative
perception of the Critical Patch Update in term of its contribution to the security posture of the
organization is related to the beliefs that security patches are not required or are too cumbersome to
implement. It would be interesting to further analyze such answers in future surveys.

4) The absence of organizational requirements for CPU application, the
   inexistence of previous malware outbreak, and the complexity
   associated with testing changes in production environment are major
   obstacles for timely deployment of Critical Patch Updates

Respondents were asked to select up to three factors that could cause them to apply Critical Patch
Updates more quickly and consistently. Figure 5 below provides a breakdown of the responses
received as a percentage of the total number of answers.
                                                   8



 Figure 5: If anything, what would cause you to apply Critical Patch Updates more quickly or
 consistently?




These findings highlight the equal importance of organizational requirements and the availability of
tools or documentation simplifying the application of Critical Patch Updates (particularly as it relates
to testing Critical Patch Updates before their deployment in production systems) as factors likely to
have a positive impact in security patching behavior. Together requirements from security staff (6%),
security audits (13%), and executive mandate (17%) account for over one third (36%) of the total
number of answers given. At the same time, enhancements to tools (18%) and documentation (16%)
account for another one third (34%) of the total number of answers.

Surprisingly, sixteen percent (16%) of the respondents indicated that a massive malware outbreak
would result in changes in their patching behavior. And ten percent (10%) of the respondents
indicated that they didn’t feel the need to change their patching behavior. Unfortunately, the online
survey application didn’t provide for determining whether the respondents who reported no need to
change their patching behavior (10%) were the same who reported that they never applied a Critical
Patch Update (11% of the respondents in a previous question).
                                                           9




Conclusion
While limited in scope, this survey has the merit to bring to light certain behaviors in regards to
security patching in Oracle environments. The key findings of this survey are as follows:

1) Organizations need to define and enforce formal security patching policies across their
    environment in order to maintain an adequate security posture.
Various IT governance frameworks, such as ITIL2, ISO-270013, or COBIT4, typically recommend that
formal policies be in place to govern patching across the environment. The purpose of these policies is
typically to ensure that security patches be applied as a means to maintain the security posture of the
organization, and by exception, these frameworks typically require that conscious non-patching
decisions be documented and justified. However, the results of this survey seem to indicate that it is
typical for Oracle systems and database administrators to be required to justify the deployment of
security patches. From a security perspective, it seems more appropriate that organizational policies
require that the non-deployment of security patches be justified in light of the absence of security risks
they create or because of the presence of other mitigating circumstances, or availability of other
preventive security measures.

2) Cumulative Critical Patch Updates and the inclusion of security fixes in Oracle patch sets
    contribute to providing Oracle users with a positive security posture.
Considering that a large proportion of organizations may choose to “skip” Critical Patch Updates, the
cumulative nature of the Critical Patch Updates for many Oracle products provide a significant security
benefit in that it allows organizations the ability to quickly “catch up” to current security patch release
level.

3) The fear of negatively impacting the availability or performance of production environments is a
   major obstacle to the application of security patches.
The patching practices on database and application servers are very different from those encountered in
desktop environments. The requirement for extensively testing patches across complex and large
production environments are primary difficulties against timely application of Critical Patch Updates.
While the application of the patches may take a few hours, the actual testing of the patches before their
application in production systems may take months in some organizations.

The detailed findings of this survey have been presented at the Security Customer Advisory Council,
and discussed with Oracle Global Product Security on various occasions. During the Security
Customer Advisory Council, council members strongly emphasized that more so than the installation
of the security patches themselves, the greatest challenge lies with the testing of security patches (and




2
  http://www.itil-officialsite.com/home/home.asp
3
  http://www.iso.org/iso/catalogue_detail?csnumber=42103
4
  www.isaca.org/cobit/
patch sets) prior to their deployment to specifically make sure that the “applications do not break.” As
a result of the findings of this survey and the resulting discussions at the Security Customer Advisory
Council, Oracle has announced it would look at ways to further educate customers about the
importance of security patching and will be looking at ways to bring further enhancements to the
Critical Patch Update documentation in order to help customers determine which areas need to be
tested in their environment prior to the deployment of Critical Patch Updates against production
systems.




Visit the IOUG website for more information - www.ioug.org

								
To top