A few weeks ago both
Microsoft and
Apple released updates for some of their solutions. The process for upgrading was simple for each product, but annoying since each product uses its own update engine. These updates made me think how many actual update engines are currently present on my home and business computers.
Let's take a quick count: Microsoft for Windows and office, Apple for iTunes, Adobe for Acrobat and flash, Oracle for Java, DisplayLink for video drivers, VMWare, Sprint for broadband access, eEye for my own company software, GotoMeeting by Citrix, HP for printer drivers, and Dell managing miscellaneous drivers included with the system.
At a minimum this is 11 different update programs routinely checking for security and maintenance patches to correct my system. Like many clients, each of these runs automatically when Windows starts and consumes resources. I have separate firewall rules for each and their update schedules are predominantly erratic.
Recently, new malware has been taking advantage of insecure update engines, infecting hosts with additional viruses and preventing updates by making the entire process suspicious. Unfortunately, there is no easy way to mitigate all of these vendors and patches with one solution and verify communications and activity. Patch management vendors only carry a few of the vendors listed and it is up to the system administrator to stay up to date with the rest of the security patches.
The bigger question is, how do you know when your system is out of date and can be exploited via a vulnerability?
Vulnerability assessment solutions like Retina can identify when patches are missing and provide the missing information when there are no automatic updates. In most businesses, users are not permitted to automatically update their systems only the administrator. A vulnerability assessment solution provides the vehicle for an administrator to determine what should be patched, how to test the solution, and when to properly schedule the change according to current change control procedures.
So as a matter of best practice, consider these five things when managing patches for third-party applications:
1. Take an inventory of your common office environment and determine which programs use auto update engines and more importantly, which do not.
2. If possible, disable each of the auto update engines to save system resources and potentially unwarranted outbound connections.
3. Perform a vulnerability assessment on a regular basis to determine which third-party patches need to be deployed to keep the endpoint secure.
4. Download and test each patch and determine if it is safe to deploy to the entire environment.
5. Use a mitigation procedure such as patch management and vulnerability assessment to verify patch deployment and remediation of vulnerabilities.
Essentially, after this little exercise I have stopped all my auto update programs and rely exclusively on my vulnerability assessment solution to tell me when to patch on a routine and predictable basis. Then I can run the tools manually to retrieve the patches, conserve resources, prevent unwanted outbound connections, and mitigate the risk of malware taking control of my update engines.
This practice is not necessarily viable for every home user, but strongly recommended for businesses where the end-user is not permitted to perform the updates themselves.
