Security Solutions: Enter, Virtual Patching

A few years ago, OS and Application patch was barely a blip on the radar screens of most security and IT personnel. Install and forget was a fairly common practice; once deployed, many systems were infrequently or never updated. Obviously, for a number of reasons, this approach is no longer an option. The rise of widespread worms and malicious code targeting known vulnerabilities on unpatched systems, and the resultant downtime and expense they bring, is probably the biggest reason so many organizations are focusing on patch management. Along with these threats, increasing concern around governance and regulatory compliance has pushed enterprises to gain better control and oversight of their information assets.

Patch deployment for vulnerability remediation can be a painful exercise for the IT departments. If it were easy, patch release and deployment would be predictable events and vulnerabilities would be addressed within acceptable timeframes. Instead, emergency patches persist, IT staffs scramble to deploy them, and security officers brace themselves for the worst casea data breach or unplanned system downtime.

Why Patch Management?

The primary goal of software patching is to keep operating systems and applications working smoothly and securely. The mere availability of a patch doesnt give IT a green light to deploy it across all business systems, especially critical servers. Even the very predictable Microsoft Patch Tuesday releases are scrutinized every month by the IT organizations to ensure that the risks are actually addressed without breaking the existing applications. Typically, patch deployment follows a structured process that includes obtaining the patch from the Application vendor and check the integrity, deploy in test environment, notify stakeholders to deploy the patch to all affected systems, and rechecking operational efficiency of the patched systems. The complexity and the time taken to deploy the patch on the critical server systems are significant burdens on the IT operations and consign them to a state of reactivity and continuous catch-up.

Against this background, it is hardly surprising that the IT departments spend 33% of their time on patch management, but only 27% rate their patch management process as being effective. More than 86% of enterprises reveal that they have experienced security breaches due to malware, over a two-third have experienced attacks on web applications, and almost one-third have had OS vulnerabilities attacked. In 2009, over 5,700 critical software flaw vulnerabilities were reported in operating systems, databases, servers, and other applications, according to the US National Institute of Standards and Technology (NIST). Patching these vulnerabilities can be disruptive and time-consuming, requiring systems to be rebooted and potentially impacting service-level agreements. Even when a patch is available, it can take weeks or even months before the patch can be fully deployed because of internal testing requirements. The challenge is not getting easier over time, with the National Vulnerability Database reporting an annual average of close to 6,000 software vulnerabilities between 2006 and 2009. Buying time to manage the window between when vulnerability is discovered and a patch can be deployed is a critical element in maintaining an adequate security posture.

The Associated Challenges

Clearly no software application will be supported in perpetuity; every IT manager has at some time received an End of Life (EOL) announcement, which specifies a date after which a particular program will be out-of-support (OOS) and no further patches will be issued except by special (and costly) individual agreements. Yet even with an organized end-of-life process, many organizations appear to be caught off-guard or unprepared for the inevitability of OOS software. And, those who do research the options find that those options often bring their own share of challenges.

Patch management is both a solution and a source of frustration, so why do IT security policies continue to mandate timely and accurate patching of vulnerable systems? The answer is that, short of rewriting the original source code, patches are the most targeted way in which to remediate software vulnerabilities in specific operating systems and applications. In addition to OOS software, a number of other critical IT areas like enterprise applications, legacy web applications, and non-typical systems are also vulnerable to the ignorance is bliss school of security management. In addition, the broad interconnectedness of todays systems has expanded the perimeter of the corporate network well beyond the physical boundaries of the enterprise. Users personal smartphones and USB drives are frequently plugged into corporate endpoints, social networking applications are downloaded without the knowledge of the IT department, remote users may only occasionally connect to the corporate network and receive patchesand all have the potential to create a direct connection between the network or data center and whatever might be lurking on the internet. So, human behavior remains a top cause of security breaches in business today.

A New Approach: Virtual Patching

The dual challenge of vulnerability risks and patch management is clearly not being adequately met by traditional solutions. Multiple gaps exist that need to be filled by a solution that does not require the isolation of critical systems, entails white-listing applications on critical systems, calls for the removal of unused user accounts and unnecessary services, further reduces security and operability by blocking ports, and involves IT in attempting to block social networking and smartphones. There are lots of tools available in the market, which produce reams and reams of data. But, one needs a different tool that actually helps us to focus on the right issues. The answer to the unwinnable challenge of patching unpatchable systems is a virtual patching tool that is non-disruptive vulnerability shield and protects systems during the risk window.

It should be capable enough to shield vulnerabilities in critical systems until a patch is available and deployed or in place of a future patch that may never materialize.

If a hacker locates vulnerability, he may try to exploit it. Thats why it is a great idea to have a tool that also has Intrusion Detection and Prevention (IDS/IPS) mechanism. This will help in shielding against known vulnerabilities like those disclosed on Microsoft Patch Tuesday from being exploited. In addition, it should also be capable of checking for updates to IDS/IPS rules. The tools also should have a web application protection rules to defend against SQL injections attacks, cross-site scripting attacks, and other web application vulnerabilities, shielding these vulnerabilities until code fixes are completed.