Importance of Patching Non-Microsoft Applications
Patch Management has become crucial part of IT administration and administrators fell the need to patch the third party software’s or risk the networks security.

Gartner states in its report - report - Top 10 Steps to Avoid Malware Infections that “IT organizations must strive for continuous improvement in vulnerability detection and rapid security patch management, especially in often overlooked non-Microsoft components that are Web-facing.” According to research released last year by the CSIS Security Group A/S, 85% of all virus infections occurred as a result of automated drive-by attacks created with commercial exploit kits – targeting 5 applications: QuickTime, IE, Adobe Acrobat & Reader and JRE.

All Internet-based applications, especially browsers and browser plug-ins (i.e., Adobe and Apple QuickTime), should be a top patching priority.  However, due to the un-predictable nature of 3rd party patches, deployment of non-Microsoft patches is often significantly slower and less organized.

 

How and when to patch Non-Microsoft products
Microsoft products can be patched with Windows System Update Service (WSUS).   However, non-Microsoft patches are not supported by WSUS and administrators can resort to manual patch process or purchase automation software for third party patch management. Manual patching can be done by pushing the software by manually preparing each server for patch deployment. Patch deployment to end-user can by deployed by using Group Policy along with Update Management. By editing group policy windows update agent can scan WSUS server for latest patches. Administrators can define when to deploy and scan the WSUS server for updates.

Another option is patching non-Microsoft products using System Center Configuration Manager.  This product provides the capability for creating the package, but does not provide the content itself – so administrators must still research, package and test the patches.

If going the manual route, administrators should plan patching based on business requirements (security/bug fix) and when they have time to schedule them.  To determine what needs to be patched, administrators can visit the third party sites that have the latest patch information.  Adobe, Oracle, and other ISVs normally describe the contents of the patch and sometimes flag the type of patch (severe, critical security update, bug fix, etc.).  Unless the patch is critical, the good option is to schedule the patch updates once in month so it reduces time spent on patching and prevents application performance issues related to patch updates.

 

Check out this table on Patchzone for the most recent patches available for 3rd party applications.

 

 

Here are some other links for reference:

Microsoft Security Bulletins  http://technet.microsoft.com/en-us/security/bulletin

Adobe Security Bulletins & Advisories: http://www.adobe.com/support/security/

Mozilla Security Bulletins http://www.mozilla.org/security/announce/

Apple Security Bulletins http://support.apple.com/kb/HT1222

Oracle Security Bulletins http://www.oracle.com/technetwork/topics/newtojava/overview/index.html

 

Automating patch management can save a lot of time
The manual route has its limitations.  Researching, building, testing and deploying patches are extremely time consuming tasks.  If your company has a large number of vulnerable servers, you should definitely consider purchasing patch management software.  What you should look for:


• Catalog of 3rd party patches –Most vendors support Adobe, Java and most browsers.
Before and after patch deployment scenarios – especially important for Java.
• A mechanism for scheduling where and when patches are deployed
• Support for creation of custom application packages.
Reporting for vulnerability assessment and patch compliance.
• Scalability – the software should scale to a large number of servers & desktops.