Oracle on the psychology of patching

Oracle on the psychology of patching

Summary: Oracle has a belated reply to a survey a few weeks back on how database administrators have never installed one of the company's critical patch updates.In a blog post Oracle's Eric Maurice faults the survey for relying on a small sample size--not that it stopped us from reporting it.

TOPICS: Security, Banking, Oracle

Oracle has a belated reply to a survey a few weeks back on how database administrators have never installed one of the company's critical patch updates.

In a blog post Oracle's Eric Maurice faults the survey for relying on a small sample size--not that it stopped us from reporting it. But Maurice then takes an interesting detour to the psychology of patching. In short, patching stinks, but it may not be nearly as bad as you think.

The problem is that there are unintended consequences to patching. The biggest fallout can be a bunch of broken applications. That risk is weighed against being vulnerable to attackers. Maurice writes:

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?

That's an interesting point. Maurice's fix is even more interesting:

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.

In a nutshell, the choices outlined by Maurice are force feeding vs. ROI metrics of patching. Obviously most of us would opt for the metrics, but as Maurice notes there aren't any actuarial tables for patch procedures.

Nevertheless, I'm sure the industry could agree on some standard way to measure the ROI involved with patching. More likely though is that patching will be increasingly be mandated along with maintenance. What do you think? Should patching be mandatory?

Topics: Security, Banking, Oracle

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Patching is absolutely mandatory

    I agree that there are two ways to think about patches; mandatory and impact based. But there is no way to guage potential impact to an event that might occur due to not applying a patch, and there is also no way to guage the probability that the event will occur. Typically we look at the potential impact of an event as the sum of probabilities times their weights (some arbitrary measure of their impact on the company, Dollars works well). So let's say that the probability of an Oracle system being breached due to a patch not being applied is 1%, and the impact of the breach is $2M. Then the weighted impact is $20,000. Now you can estimate if it might cost you more than $20K to apply the patch. Sounds nice, people love exact numbers, however remember that the inputs are wild guesses. How could you ever know the probability of the event occuring in the future without gathering data on other users who have not applied the patch? You could not, that is why all patches should be applied. You never know when a "bet the company" event will occur otherwise.
  • The Sample Size Was Fine

    While the sample size was "small" (300+ really isn't that small for this type of very targeted and specific survey), does anyone believe that the results would be any different if the same questions were posed to more OUG attendees? Not likely.
  • RE: Oracle on the psychology of patching

    For those that must comply with PCI DSS, patching is already mandatory... but the real solution to this problem is vendors shipping better quality code that doesn't require patches. Vulnerability researchers take a lot of flak from various quarters for forcing vendors to issue patches - that's not their aim - the aim is to get the vendor to look at and fix their development procedures and produce more robust code negating the need for patches and move to a model where any remaining flaws are so few and far between and have such little impact that they can be addressed in a service pack once every two, three years. Microsoft's SQL Server is the poster boy for this... For SQL Server 2000 there's been 1 service pack since 2003 and no security patches (except 4 in MDAC but not SQL Server specific) and 2 service packs for SQL Server 2005 and no security fixes. SDL works... Now, all we need is the other vendors to get to the same point.
  • DB Patches is a sore subject for IT

    There are a multitude of reasons DBA's do not patch.
    -Many times the patch sets simply do not apply to the current environment. Example patch sets to correct items that are not active in the current database environment. ex. LDAP patch for people not using ldap. XML patches for those not using Oracle's XML engine.
    -Databases are the backend of most applications, not vice-versa; so the DBA's are held to the app provider certifying the application with the patch set and the app provider, whether in house or external are usually more focused on new features and are not willing to dedicate the appropriate resources to certify older versions of the code. Bad thing I know, but true.
    -Many times the db is in a backend protected environment with firewalls preventing all but certain IPs on limited ports to connect to them so the DBA staff weighs ligitimate security risk to risk of downtime on the application side since in many instances there is no way someone can connect to the db except through authorized channels.
    -O L D installations. I am aware of some installs of Oracle 8i OPS still in existence that all the original designers of the infrastructure are no longer available and since Oracle no longer support this version the IT group is scared to even patch the server os that it is running on in fear of breaking what was known as one of Oracle's most fragile environments.
    - Oracle support line. When you patch and something breaks, Oracle support is a pain.
    - Uptime SLA's In today's online environments it is almost expected to have 24 x 7 x 365 uptime, leaving no time for maintenance, I know it is unbelievable, but unfortunately companies are agreeing to these type of SLA's for some reason.
    - DBA cost and availability. DBAs are expensive, overworked and getting a quality dba can be challenge. Oracle is more difficult to manage than SQL Server and requires more professional and seasoned dbas. There are simply not enough "qualified" and "seasoned" dbas around, so the IT staff that has no Oracle dedicated resources are scared of "messing" with the database.

    In a perfect environment it makes sense to patch every single thing, but it is almost impossible to keep up to date on every patch when you have a real 7 x 24 production environment. When patching is mandated then it makes some applications simply not affordable to maintain, it is sad when you pay as much as you do for a product like Oracle that they have as many patch sets as they do. It used to be you would cringe at the hardware costs, now that is the easy part to swallow and software and maintenance + the cost of qualified DBA's is financially ruining companies.
  • Oracle patches are hell

    At our company, we are a fully exclusive Oracle DB and ERP shop we're always running many major versions behind and it's very hard to get patches approved. Over time there have been too many issues coming out of patches and too many programmer man-hours wasted on them, so now our IT management demands hard proof that an upgrade our patch will specifically fix a problem we're having before considering feeding it into a full 4 month release cycle to get to production. And that's all Oracle's fault. We run Windows patches monthly.
  • RE: Oracle on the psychology of patching

    Patches no matter who puts them out are always viewed as pure hell to implement. Having said that I think that it becomes the end user to implement patches that apply to the problem rather than wait for the creator of the program to come out to site and repair the whole thing. I would rather apply a patch now and save the company money than call a company representative out from oracle to reinstall my complete OS to include all patches just because I was too lazy or concerned that my system might crash.
  • Is Oracle going to guarantee patch reliability?

    I didn't think so.
  • When you buy Oracle, you need to budget for your DBA(s)

    Oracle recent (last 2 years) SME campaign falls down in one major point. You need at lease one professional DBA to manage your databases. CPUs are just one reason.

    When a new CPU is released you need to assess every database you manage. The biggest reason these days to assess a patchset aginst your databases is compliance. Some organisations have legal obligations to design and follow a process that insists on it.
    When you do assesses your databases some systems dont need it (not using certain components), some systems have other safeguards in place and some systems just wont work with it; but when you consider that the latest CPU addresses hundreds of issues and is 1.6 GB in size, how easy is it ?

    The only safe appoach is expensive testing with and experienced team. Unfortunately, this is just a part of the cost of using Oracle.