The gap between vulnerability and protection is a distance that can be measured both by the amount of time that sensitive database information goes un-patched and by the extent of damage caused by a potential data breach. While organizations understand the stakes involved in leaving their systems un-patched, quite often they do not install patches in a timely manner. Is there a convenient and reliable way to bridge this gap?
The Window of Risk.
It has precious little to do with street noise, noxious air, rain and snow, or cold temperatures.
Closing this window won’t deliver peace and quiet, breathable air, or shelter from the vagaries of foul weather. But it will deliver a measure of comfort and protection.
When it comes to IT security as it relates to databases, the meaning of the phrase “Window of Risk” carries with it particular significance.
That very significance is rooted in the notion that database security vulnerabilities should be patched as soon as possible once they have been discovered. Dealing with those vulnerabilities makes the issuance of vendor patches an integral part of the database security cycle.
Vendor Patches as a way of Securing Databases
Database software vendors have answered the security call with their own approach to defending databases from the exploits and potential breaches caused by hackers.
Such companies as Oracle, Microsoft, and IBM, as well as others issue security patches to close vulnerabilities that they have uncovered through their own testing or that have been brought to light through the efforts of independent ethical researchers. Sometimes the discovery is made as the result of one of their customer systems being breached.
Each database management systems (DBMS) vendor has its own approach to the process but the intended result is the same.
Oracle issues Critical Patch Updates (CPUs) as the core method for releasing security fixes for its products and releases the updates on a quarterly basis. Microsoft makes use of a monthly process that is referred to as “Patch Tuesday”, which sometimes includes fixes for Microsoft SQL Server and users are encouraged to update their database servers as soon as possible.
Clearly, a variety of vendor issued database software patches are available on regular basis—with varying degrees of frequency.
But in many cases, a large number of organizations hesitate to install them or sometimes do not install the vendor patches at all. This reluctance is traceable to a number of reasons that are understandable but it still creates a level of exposure to potential hacking exploits.
Delay in Installing and an Inescapable Irony
The result of this hesitancy is a “Window of Risk”, i.e. the period of time between the issuance of a vendor security patch such as a CPU and the actual installation of the patch.
And the danger of a potential attack is heightened by one of the most striking ironies one can find in the world of software security: the release of a patch that is so clearly intended to protect database software can actually serve to increase the likelihood that more attacks will occur.
The facts that lie behind this irony are very instructive: since patch releases receive a generous amount of publicity, hackers benefit from something of a heads up that if they are going to strike then the time is ripe.
Within a very brief period of time after a vendor patch has been released—sometimes this can be a matter of days or even hours—the community of hackers has acquired critical amounts of information about the nature of the underlying problem and how to take advantage of it as a way of gaining entry to database servers that remain un-patched.
In addition to this period of heightened risk, organizations face an increasingly strict compliance structure in the form of standards and legislation that places demands on them, assessing fines and penalties in case of a breach.
Public companies have to comply with the data security controls that are laid out in Sarbanes-Oxley (SOX), while organizations that work with private medical records come under the purview of the Health Information Portability and Accountability Act (HIPAA).
Similarly, any business, institution or organization that accepts debit or credit cards is bound by the strictures of the Payment Card Industry Data Security Standard (PCI DSS).
The severe price that businesses have to pay as the result of a breach—regardless of the type of vulnerability that has been exploited—has been documented repeatedly and in great detail—leaving no doubt as to the damage, monetary and otherwise, that hackers can create.
Considering all of the elements that ratchet up the potential trouble that can befall an organization within the Window of Risk, the results of an Oracle User Group (OUG) study from last September are a source of concern.
Why the Delay in Installing Vendor Patches?
Of the 430 Oracle database administrators, consultants and developers who were surveyed only 37 percent installed Oracle CPUs within three months after their release date. With all these facts in evidence, the 800-pound Gorilla in the room comes in the form of a simple question.
Why, if the dangers from hackers are so clear, the damage from a breach so severe and the requirements of standards and statutes so exacting, do organizations delay the installation of vendor patches or, in some cases, neglect to install them period?
For one thing, because patching is an update to the DBMS kernel, it requires database downtime, which spells trouble for environments that demand 24×7 availability.
And before installation, to be certain that the vendor patch update doesn’t have a negative impact on other software; most organizations decide to perform extensive regression testing of all of the applications they have that run on top of the database.
Beyond those issues, some of the older versions of database software are no longer officially supported by the vendor—some examples include Oracle 8i and 9i—so patches are not made available for those versions. Problem is, many of those older versions are still widely used.
So, while the reasons for the delay or the decision not to install are understandable, the threat doesn’t go away.
An Approach to Bridging to Gap
But a method for closing the Window of Risk without disrupting production does exist and takes the form of virtual patching.
Virtual patching can be used to identify attempted attacks by monitoring all of the activity that occurs in the database memory and detecting “fingerprints” of known exploits and vulnerabilities.
When a match occurs, an alert is issued in real time and the session in question can be terminated. Moreover, the user who initiated the session can be quarantined for a specific time until the nature of the suspected attack can be looked into.
Virtual patching can be an effective way of meeting compliance requirements for patching by lessening the risk of a long interval in between the issuance of vendor patches and their actual installation.