Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Managing client-side security with patch management best practices

Attacks on applications like Adobe Reader and Java require effective and timely patching of user systems.

The pervasiveness of Microsoft Windows has made it a favorite target for hackers for years, but client-side applications like Adobe Reader and Flash Player are even more ubiquitous -- a fact that hasn't escaped criminals. Dangerous vulnerabilities turn up in Adobe products on a regular basis. But it's not just Adobe vulnerabilities that put systems at risk. Serious security flaws have been found in other common client-side applications, such as Java, Apple QuickTime, Mozilla browser extensions, and Opera widgets.

Microsoft and many large vendors now release security updates and patches to a known timetable, and Microsoft products like Office can be automatically patched using the Windows Automatic Update. However, patches for other common applications such as Adobe Reader, Firefox, and Java can't. Relying on end users to manually install these patches distributes the patching workload but in no way is this ideal as users can't be relied upon to get all the patches installed on a timely basis.

The timely patching of software vulnerabilities is critical to maintaining the operational availability and integrity of enterprise IT systems. Patching proactively prevents the exploitation of vulnerabilities but the failure to keep application software patched is one of the most common reasons why hackers are successful. Most major attacks in the past few years have targeted known vulnerabilities for which patches already existed. Although many organizations are competent at keeping their critical servers patched, the same level of attention isn't given to their users' desktops and laptops, even though statistically this is where most vulnerabilities occur.

According to vulnerability research company Secunia, the average computer needs about 76 patches per year from 22 different software companies. The logistics involved in keeping this number of applications patched is one of the reasons many applications remain unpatched. Read on for insight into how enterprises can manage the security of client-side applications and integrate fixes into existing vulnerability management programs.


The single most effective method of improving patch management of client-side applications is to implement a standard build for desktops and laptops. A standard build will satisfy the vast majority of an enterprise's workforce and will help improve overall security. It reduces day-to-day maintenance and support costs, the number of different vendor alerts to follow and patches to test and deploy, and reduces the cost and time and overall burden of patch management. If every PC is configured differently, it becomes impossible to test patches on every permutation, leading to roll out problems and increased downtime.

Some employees will need non-standard applications and configurations but this should be the exception not the rule. An application whitelist and controls to prevent users loading their own software will help control the number of applications you have to manage. To ensure non-standard machines are correctly maintained and patched, an up-to-date register of hardware and software should be established, recording installed applications, version information and all patches installed. If this register doesn't exist, Nmap is a free tool that can quickly gather this information. Each machine should be grouped both by function, configuration and network location and assigned a priority level. This helps to quickly identify which systems are most at risk to a particular vulnerability.

Even with standardization, most businesses will still need to support a variety of applications from multiple vendors.


To avoid the risky situation of unpatched machines on the network, most enterprises need to use an automated tool that pushes patches for different applications from different vendors from a central point. One such tool is Secunia's Corporate Software Inspector (CSI). Its Network Appliance Mode enables you to setup a CSI Agent as a remote-controlled dedicated scan engine, capable of automatically scanning complete network segments at scheduled intervals. It can identify about 13,000 applications from 2,300 companies on any network connected machine, providing a complete software asset register, listing all the programs and plug-ins installed on each machine and whether they're patched and up-to-date. The enterprise version allows you to automatically repackage a large number of patches from different vendors for direct deployment using groups and configurations from Microsoft's Windows Server Update Services (WSUS) or System Center Configuration Manager (SCCM).

Application patch status is checked by comparing installed programs against Secunia's Vulnerability Intelligence database. The breadth and depth of this database means it can produce very accurate and detailed status reports, including criticality ratings for each insecure program along with detailed information about why it's insecure. It shows the full installation path, version details, and direct links to patches and Secunia Advisories which provide additional details and metrics about the vulnerability as well as other useful information for alternative mitigation strategies.

Reports can also be used to verify that patches have been properly applied, old insecure versions have been removed and to track the installation of non-approved applications, which is great for audit and compliance reports. It even lists end-of-life programs. Software which has reached end-of-life should not be used due to a lack of vulnerability information and the end of the vendor's commitment to providing security updates.

Other automated tools include Desktop Central, which supports managing both Microsoft and non-Microsoft patches as well as pushing standardized application configurations to Windows machines on the network. It automatically identifies the new and latest updates, identifies the systems that need them and installs them. ManageSoft Security Patch Management provides a similar service, distributing and installing patches to Windows, Linux, UNIX, and Mac machines. It's important to note that any central patch management server needs hardening and protecting against malicious attack to prevent it being used as a tool to distribute malicious code.

When considering an automated system, you need to ensure that it can patch and update the software applications in use within your organization. How it handles rollbacks of troublesome patches and tracks implemented patches for audit purposes are also important features to provide assurance that vulnerabilities have been identified and appropriate patches have been installed. Enterprise patch management tools are less efficient when unique deployments have to be managed, which is another reason why standardization is good idea.


Knowing which patches to install and when is another key element of good patch management. When a patch is released, attackers immediately try to reverse engineer it to identify the vulnerability and develop exploit code. This means the risk of attack increases immediately after the release of a patch due to the time lag in obtaining, testing, and deploying it. Vulnerability criticality ratings are an important aid to help you prioritize your patch process and accepted practice is to concentrate efforts on patches rated as critical and leave the others until a more convenient time. However according to CERT, hackers are now starting to focus on vulnerabilities with lower ratings because they know it's likely that the relevant patches won't necessarily be installed so quickly.

This complicates the process of patch prioritization and is why a risk-based approach is so important. All patches applicable to your software need to be recorded, but the first check is to see if it is relevant to your environment: Does it correct a vulnerability or problem in an application as it is being used within your organization?: For example, if your organization disables browsers scripting languages then applying patches that fix scripting languages vulnerabilities is not a priority. Other security controls may also automatically mitigate certain threats, again reducing the urgency to apply certain patches. If the vulnerability does put the organization at risk, prioritize the patch by evaluating the impact it would have if exploited; for example, unauthorized system access, information confidentiality, arbitrary code execution, or denial of service.

If the overall degree of risk is not acceptable, then you must either apply the patch or pursue non-patch remediation; assume that exploit code is available for any vulnerability for which there is a patch. The next step is to determine whether the fix will affect the functionality of other software applications or services through research and testing. Testing should be performed on a selection of systems that accurately represent the configuration of the systems in deployment, since so many possible system configurations exist that a vendor can't possibly test against all of them. Check that all related software still operates.

A virtual test lab is essential for the efficient testing of patches on different platforms and configuration. It greatly reduces your investment in hardware, space, and general overheads. It also means local administrators don't have to duplicate patch testing on their particular systems as they can all be replicated in the test lab.


If applying a patch will impact business processes, you will need to agree to an appropriate time for patch installation and necessary downtime with system owners. When patch deployment has to be delayed, it may be possible to for some other compensating controls to be put in place. Known as virtual patching, changes such as a new firewall rule can eliminate the vulnerability by controlling inputs or outputs from the affected application; even the temporary removal of the application may be a sensible temporary option.

However, certain client-side applications and plug-ins, such as Adobe's Reader plug-in, are going to be difficult to do without. In such instances, look for other ways of thwarting any potential exploits. For example, most users will not be inconvenienced if executable code embedded in a PDF document is disabled. Disabling JavaScript within in Adobe will help prevent some of the more common exploits and you can still read a PDF document without JavaScript enabled. Many attacks can be successfully frustrated by ensuring that your users aren't logged on to their system with unnecessary elevated privileges; the majority will not need to have administrator rights on their desktop. This makes it a lot harder for an attacker to take complete control or cause widespread damage. Local administrators need to be informed of all vulnerability and remediation decisions.

Java exploits on the rise

Cisco researchers say criminals now prefer Java over PDF 

Criminals last year began targeting Java more heavily than PDF to launch exploits, according to researchers at Cisco Systems.

According to the Cisco 2010 Annual Security Report, Java exploits made up 1.5 percent of Web malware blocked by Cisco ScanSafe in January 2010. By November, that number jumped to 7 percent. In comparison, PDF exploits dropped from slightly more than 6 percent to just 2 percent in the same time frame.

Cisco researchers surmise that the shift has to do with a number of factors, including increased availability of public Java exploit code and decreased availability of public Adobe Reader and Adobe Acrobat exploits. Some users also have shifted to other PDF readers or disable JavaScript in Reader.

The Blackhole, Crimepack and Eleonore exploit software packages make heavy use of Java, according to Cisco, which notes that Adobe Reader and Acrob at remain strong threat vectors online.

McAfee Labs, however, said malware developers heavily exploited weaknesses in Adobe products -- Flash and particularly PDF technologies -- throughout 2010. Malicious PDFs targeting Acrobat topped the number of unique samples collected by McAfee Labs, "making them the favorite target of client-side exploitation," McAfee said in its Q4 2010 Threat Report. The company expects the trend to continue this year as more mobile devices and non-Microsoft operating systems support Adobe technologies.



Change management procedures should always be used when deploying patches as systematic and documented processes are far more likely to result in a successful install. Even emergency patches need to go through this change control process. Budgeted and approved resources, such as off-hours testing and overtime need to be in place to make sure that they can be handled with the necessary priority. Manual methods may need to be used for operating systems and applications not supported by automated patching tools, such as experimental systems or those not part of Active Directory or a domain. For such computers, there should be written and implemented procedures for the manual patching process.

Even with standardized configurations and after thorough testing, it's still best practice to roll out patches to a small user group first before deploying them enterprise-wide. This allows user feedback and keeps disruption to a minimum if the patch does cause a problem for some unforeseen reason. Patches should certainly be deployed to standardized systems first before updating nonstandard and legacy machines.

Post roll out tasks include verifying the patch installed properly by reviewing patch logs, checking that the vulnerability has been mitigated using a vulnerability scanner, updating configuration documentation, and documenting the decisions behind installing or rejecting specific patches.

Even with automated technologies in place, system administrators still need to subscribe and follow vendor alerts, vulnerability announcements, patch and non-patch remediations, and emerging threats. Relevant Internet forums are also a great source of warnings of patch installation problems and problem solving advice, such as CERT.As with any security function, organizations need to measure the effectiveness of their patch and vulnerability management efforts, basically how quickly they can identify, classify, and respond to a new vulnerability and mitigate the potential impact within the organization. This helps highlight any shortcomings in procedures or tools.


Keeping enterprise users' machines secure is a tough task, given the relentless attacks on client-side applications like Adobe Reader and Java. Implementing effective patch management for user systems requires both technical and diplomatic skills. Getting business managers to accept that it is a regular business activity and not an optional one requires senior management support. Done well, it reduces the time and money spent responding to security breaches and helps protect the enterprise from legal and regulatory fines. Patching is much more cost-effective than responding to breaches; it's not possible to save money by neglecting patches.

Any opportunity to highlight the role patching plays in protecting the bottom line should not be missed as manual patching of computers is getting harder to do effectively. Even moderate-sized organizations need a budget for a vulnerability scanner and an automated patching tool to make the process as effective and painless as possible for everyone.

Michael Cobb, CISSP-ISSAP, CLAS, is a renowned security author with more than 15 years of experience in the IT industry. He is the founder and managing director of Cobweb Applications, a consultancy that provides data security services delivering ISO 27001 solutions. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications. Send comments on this article to [email protected].

Dig Deeper on Microsoft Patch Tuesday and patch management