Postpone patches with a patch proxy

* One approach to dealing with patches

Software maintenance has long been recognized as the most expensive part of the software lifecycle. Increased security threats have forced vendors to release software updates and patches far more often, exacerbating the cost of maintenance. But a bigger problem looms: The most critical servers in an organization are not getting patched because IT managers are extremely reluctant to expose those servers to frequent updates that may cause crashes or software conflicts.

How should we reconcile the need to limit server exposure to security threats with the risk inherent in frequent patching?

Even though software patches have been a mainstay of software maintenance for decades, it was up to IT managers to choose whether a patch added useful functionality or whether it was better to wait until the next software release. But in the late '90s, vendors started using patches to address security vulnerabilities, gradually increasing the frequency of patch releases as more and more security vulnerabilities were discovered. In an ironic twist, the cure gradually became worse than the disease, with IT organizations struggling to keep up with hundreds of new patches each year.

One solution to the patching conundrum is an inline “patch proxy” or “network patch” appliance. A patch-proxy device changes the network traffic, applying a transformation to the packets that is functionally equivalent to a patch.

For example, if a vulnerability is found in a piece of code that does not properly limit the length of a string or memory access call (a.k.a. a “buffer overrun”), the patch proxy can truncate the equivalent string in all packets. In most cases the truncation will not have any effect because the string will not exceed the server’s buffer limitations - that is, the traffic is legitimate and well formed.

Some packets will be transformed to truncate the data because the packet contains an exploit for the buffer overrun. But this would also apply to packets which contain long strings sent due to misconfiguration rather than malicious intent. Regardless of the intent of the sender, all the packets undergo a transformation that is functionally equivalent to the patch. The patching proxy thereby patches the packets in the network so IT doesn’t have to patch the servers.

There are two main advantages to this approach. First, a patch proxy can “front” many servers, providing patching services for all of them. IT administrators can either leave the servers un-patched permanently or more likely can postpone patching until the patch has been thoroughly tested.

In the meantime, the patch proxy provides inline protection so that the un-patched servers are not vulnerable.

The other key advantage is that there are no false positives or false negatives. The patch proxy is not looking for malicious traffic and does not decide whether a packet is malicious or not. Instead the patch proxy simply transforms all packets with the functional equivalent of a patch. By applying a transform to all packets, dangerous packets are “defanged.”

IT organizations struggling with patch management of critical servers and database systems should consider leveraging the network as a proxy to patching the servers.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Take IDG’s 2020 IT Salary Survey: You’ll provide important data and have a chance to win $500.