The pressure to patch servers is increasing as regulatory requirements drive rapid patch deployment. Many organisations have deployed patch-management systems to simplify and manage roll-outs of security patches, yet they're still left with the need to test and verify that patches will not disrupt critical applications.
Patch-proxy technology offers a solution to the challenge of quickly responding to new patches. Patch-proxy companies offer functional substitutes for the original vendors' security patches, in effect providing proxies for actions of the vendor patches. Instead of testing and installing vendor security patches on servers, a patch proxy can be deployed to mimic the actions of patches that are not installed.
A patch proxy can be deployed in a network or on a host. The technology is primarily software, though it also can be delivered in an appliance form factor. Patch proxies rely on frequent updates to stay current with patch releases from operating system and application vendors. These updates are pulled down automatically and deployed, much like anti-virus updates.
In a network configuration, the technology resides inline, monitoring client/server interactions, intervening when traffic accesses an unpatched server application or operating system, mimicking how the patch would perform had it been installed on the server. The patch proxy performs the same function as the patch, fixing an error in the original program, but in this case making a change in the session on the wire and forwarding the traffic to the server. The inline patch proxy makes changes to apply the necessary patches for sessions between a client and a server; therefore, it must maintain all TCP/IP session handshaking yet remain transparent to the server and the client.
A network-based patch proxy requires no software installation or modification on the protected servers. If signs of a problem arise with an inline patch proxy, rollbacks are quickly and easily implemented.
When based in a host, a patch proxy must be installed on a server as an agent, monitoring activity from the application or operating system. When the patch proxy identifies a request that exercises logic for an unpatched vulnerability, the agent injects a fix in the code that is executing. Agent installation is less likely to cause disruption to a server than frequent installation of security patches, though it does directly touch the server and the application.
Consider as an example Microsoft patch MS04-045, which fixed a vulnerability in the Windows Internet Naming Service (WINS) that maps IP addresses to NetBIOS computer names. A network-based patch proxy recognises the WINS session to an unpatched server and applies the patch equivalent action to the session traffic, which in this case validates a key value in the request. The server is no longer vulnerable to the MS04-045 vulnerability, because of the inline action of the network-based patch proxy.
For the host-based approach, the patch proxy monitors the WINS session on the host by intercepting the request and making the appropriate change to the key value before the request is processed.
Because the technology in both cases acts as a cleanser, allowing all sessions to pass but applying only the same corrective action that the patch would have performed, it delivers all of the value of the security patch. In the case of a network-based patch proxy, it also does this without requiring disruption to the server application with a (probably unscheduled) change window. Furthermore, since the action of a patch proxy is based on an actual vendor patch, it can deliver the value of the patch immediately and defend against any exploits that arise after the release of a security patch.
Fred Kost is vice president of product marketing and management for Blue Lane Technologies.