To Patch Or Not To Patch?

Hello, this is Eric Maurice!


A security vendor recently issued a press release that revealed the results of an informal survey it conducted of Database Administrators conducted at Oracle Users Group meetings throughout the United States.  The vendor allegedly found that two-thirds of the 305 respondents had never installed a Critical Patch Update.  A number of outlets including blogs and media publications commented on these findings.


It is difficult to draw firm conclusions from this survey because of the relatively small size of the sample, absence of information about representativity of the sample, and the formulation of the questions themselves.  However this survey is interesting to security professionals insofar as it reinforces the importance of patching and brings to light a new element: the psychology of patching. 


Commenting in a blog entry, Pete Finnigan made an interesting comment: �I am starting to get the impression from talking to a lot of people that the issue has become psychological, a lot of companies believe it�s difficult, that it will fail and that everything in the organization needs to be regression tested.�  Security professionals are periodically faced with the decision �to patch or not to patch.�  For some, this decision is very difficult because it comes down to weighing the known and immediate consequences of the patching procedure (significant effort for testing and deploying the patches, and the impact of temporarily affecting production environments) versus the unknown and hard-to-predict consequences of keeping known vulnerabilities unpatched (damages resulting from an incident that was enabled by the presence of the unpatched vulnerability).  It is generally in human nature to find known and immediate difficulties more daunting than those that are uncertain and more remote, though the uncertain ones might have much more critical and threatening impact.  Can the decision not to patch be likened to the decision by careless drivers to run yellow or red lights to avoid being delayed for three or four minutes, while consciously ignoring the potential price of such action (possible death or injury) if collisions were to occur? 


The only solutions for removing the psychological objections to patching are mandating the application of security patches as a part of the normal maintenance of production systems or providing objective measures to determine whether patching is required on certain systems at a certain point in time. 


Patching decisions can only become objective business decisions if they are made after computing the expected cost or benefit resulting from the application of the security patches on a given system.  The costs of the patching effort and its impact on production environments need to be measured against the probability that the unplugged vulnerability will result in a successful exploit, multiplied by the financial liability that this successful exploitation would create for the organization.  Unfortunately, there is no such thing as an actuarial table that would provide accurate statistical measures of the chance of occurrence of a specific incident or exploit; and furthermore, measuring the full financial impact (direct and indirect costs) of a potential incident is extremely difficult, therefore a lot of guesswork has to take place.  This is why most security-conscious organizations require mandatory patching, instead of attempting to develop a comprehensive quantitative risk model for all their systems in their environment.


Oracle recommends that customers apply the Critical Patch Updates when they become available to maintain a proper security posture.  However, immediate and systematic application of every security patch on an ongoing basis for all production systems may be difficult or impossible for some organizations because of the complexity of their environment or due to their production requirements.  This is why Oracle has intentionally designed the Oracle Database Server, Oracle Application Server, Oracle Enterprise Manager, and Oracle E-Business Suite R12 patches to be cumulative.  As a result, each Critical Patch Update for these products contains the security fixes from ALL previous Critical Patch Updates.  The benefit for customers is clear: applying the most recent Critical Patch Update will install all the fixes that were previously released for these products.


Note that customers, who are applying the most recent patch sets also get the benefit of previously released security fixes.  That is because security fixes are also included in patch sets and in new product releases (Oracle�s policy is to first fix security vulnerabilities in the current code, i.e., the code used for the next release of the product).  The inclusion of security fixes in patch sets and product releases provides customers more patching flexibility, effectively allowing those who are planning to deploy the most recent patch set to �skip� the application of a Critical Patch Update. 


When looking at the previously discussed survey, one is left to wonder if the inclusion of security fixes in patch sets had the undesirable consequence of causing some Oracle DBAs to mostly ignore Critical Patch Updates, opting instead to focus resources on applying patch sets.  However, Oracle recommends that the Critical Patch Updates remain the primary means of applying security fixes because Critical Patch Updates are released more frequently than patch sets and new product releases. 

You can find more information about Oracle�s security lifecycle policies on the Security Vulnerability Fixing Policy and Process page on Oracle Technology Network.  The Critical Patch Updates and Security Alerts page also on Oracle Technology Network provides detailed information about previously released Critical Patch Updates and Security Alerts.  Additionally, the Resource Library on the Oracle Software Security Assurance web site provides a number of links to useful security resources, including a white paper discussing how to develop a repeatable Critical Patch Update process


Post a Comment:
Comments are closed for this entry.

This blog provides insight about key aspects of Oracle Software Security Assurance programs.


« December 2016