This month I am going to pass on some wisdom about one of the cornerstones of all our managed service packages, patch management.
What is it?
Patches are a way of distributing fixes for known security vulnerabilities and also corrections for the way data is passed and handled in an application or operating system. Occasionally, as is the case with Microsoft Service Packs (SP) it is a way of introducing enhancements and new features.
Software applications and operating system code or, at its most basic level, binary code are inherently flexible and capable of being programmed to handle many varied tasks. Because the types of data that are handled and the methods of passing it from one process to are so varied it has been noted that it may never be possible to make software totally safe and secure.
I couldn’t really comment about this as I don’t get involved with it at such a fundamental level. In fact, it has been said that the only way to make a computer secure is not let it communicate with anything else or let anyone access it – which isn’t very useful.
In the real world, weaknesses are found in the software and patches are created to solve this problem. New versions of an application will often eliminate a weakness but more often than not will also introduce new unknown issues.
Why we do it
Best practice suggests that the best way to stay safe is to make sure your systems and applications are patched. If a weakness has been publicly announced, the bad guys will know about it just as well as the rest of the world. In fact, they will probably have a greater understanding of its implications and how it can be exploited than the majority of the world.
Making sure you have the patches in place is no silver bullet and is only one part of the security equation. However, having the most up-to-date patches will make your system more secure and the more difficult it is to compromise your systems, the more determined someone would have to be to do it.
Implications of not doing it
So what happens if we don’t bother patching? Well, immediately, probably nothing. You will certainly avoid the possibility of any software conflicts arising by introducing new patches into your environment. You do however leave your system open to a known and well documented issue. This information can used by would-be attackers and can save them hours of researching methods to get in to your system.
How software vendors do it
Most large software vendors now have an automated way in which the installed application can check back to a centralised system to see if there are any updates available. These applications can automatically download and, if given permissions, install the update.
Microsoft has a number of update methods available. At the basic level for a standalone machine the Automatic Updates service will periodically check with the Microsoft Updates website to see if there is anything available for updating. In recent years, they have extended this beyond just their operating systems to include a large proportion of their applications as well (e.g. Microsoft Office Suite).
For small and medium server based networks they provide a freely downloadable application called WSUS (currently version 3.0 SP1) which can centrally manage the approval and distribution of patches into your environment.
For large organisations that really take the process of patch management seriously, there are specialist, paid-for products from Microsoft and other companies.
What happens when it goes wrong
Why bother with an approval process? Set the automatic service to download and install the patch, job done. This is great if all the patches are flawless. Back in the real world history has shown this is not the case and the automatic download and install method could wipe out your entire business in one round of updates.
If you are more cautious, automatically download and manually install at a convenient time. This gives the opportunity to at least see if there are any problems on a test system first.
To be realistic, most of the time nothing goes wrong. However there have been some spectacular disasters in the past, especially where operating system fixes are concerned which have resulted in computers displaying a fatal system error which is referred to as the “Blue Screen of Death” (BSoD). In recent years Microsoft, have had a much better track record in this department.
Also, to be fair to software vendors it, would be unrealistic and unviable to expect them to test a patch against every application, or combination of software ever installed. As a result problems do occur after applying updates. It can be internally with the application that was patched, or more commonly with another application that used a service affected by the patch.
Why we manage the process
Patch management is one of the cornerstones of our managed services. The process of handling the deployment process can consume a significant amount of time, especially if it goes wrong. In addition, how much of the technical documentation does your on-site IT person really understand and do they realise the implications for your site?
Before we approve a patch for deployment on a client site we test it internally for any catastrophic disasters. Like the vendors, we can’t possibly test every combination and permutation of software installation and updates. We do however get to know our clients’ environments. We look at what the fix is changing so we can understand whether there are any interdependencies. We will phase the deployment of a patch on larger client sites to avoid the possibility that a faulty patch will take down the whole company.
Best of all we are available to help pick up the pieces should there be a problem with a deployed patch which is INCLUSIVE in our service.