- Jan 8, 2011
- 22,361
Source: Security Think Tank: Five strategies for dealing with software security updates
--- Start of Quote ---
What strategies can companies adopt to keep up with, and deal with, the huge volume of software updates they face?
Managing change, particularly software change, can be a cumbersome task. IT administrators and end-users often face vast numbers of patches and updates, particularly for ‘vanilla’, off-the shelf-software.
It sometimes appears as if ‘agile’ actually means ‘fragile’, given the number of emergency patches and tiny updates needed to fix one bug or another.
In practice, the days of the major service pack are over. Typical office software – just to give an example – started out with straight versioning and occasional bug fixing.
Nowadays, the same typical office software sometimes requires huge downloads of up to 100MB (sometimes even more) patches almost every day.
With such frequency, one is tempted to ask: how did software distributors ever get these previous versions through quality controls?
So, how should organisations deal with the rising tide of patches and updates, given that most of them are marked at least as important or even critical?
Here are a few practical recommendations that have worked in the past:
1. Automate and delegate
2. More emphasis on version and end-of-life monitoring
3. Stay in the sandbox
4. Use airgaps wisely
5. Manage, don’t work
Finally, it should be noted that the steps discussed above will certainly bring more efficiency, but they are unlikely to cure the root cause.
More often than not, it is up to the suppliers and distributors to streamline and improve their development and release process, rather than releasing intrinsically weak or bug-ridden interim results.
--- End of Quote ---
--- Start of Quote ---
What strategies can companies adopt to keep up with, and deal with, the huge volume of software updates they face?
Managing change, particularly software change, can be a cumbersome task. IT administrators and end-users often face vast numbers of patches and updates, particularly for ‘vanilla’, off-the shelf-software.
It sometimes appears as if ‘agile’ actually means ‘fragile’, given the number of emergency patches and tiny updates needed to fix one bug or another.
In practice, the days of the major service pack are over. Typical office software – just to give an example – started out with straight versioning and occasional bug fixing.
Nowadays, the same typical office software sometimes requires huge downloads of up to 100MB (sometimes even more) patches almost every day.
With such frequency, one is tempted to ask: how did software distributors ever get these previous versions through quality controls?
So, how should organisations deal with the rising tide of patches and updates, given that most of them are marked at least as important or even critical?
Here are a few practical recommendations that have worked in the past:
1. Automate and delegate
Most major distributors offer an automated patching and updating facility. However, many organisations still favour the old model of examining every patch in a test environment, then assembling an image or package, and finally deploying it via their own systems management.
Although this is a prudent approach, the vast majority of standard software has matured to a supplier-side patch regime that negates the need for double-checking. For example, PDF reader tools or office software may be automated without compromising security or availability.
The first step in making patching more efficient is therefore to identify less-than-critical applications, and to automate their patch regime wherever possible.
Although this is a prudent approach, the vast majority of standard software has matured to a supplier-side patch regime that negates the need for double-checking. For example, PDF reader tools or office software may be automated without compromising security or availability.
The first step in making patching more efficient is therefore to identify less-than-critical applications, and to automate their patch regime wherever possible.
2. More emphasis on version and end-of-life monitoring
There are many useful tools out there (open source and commercial) that absorb the job of actively looking for patches and updates. Most of them even enable pull solutions by the end-user, thus distributing the workload across a sizeable number of people. This is particularly interesting where an organisation has to deal with decentralised devices that cannot necessarily be updated remotely.
The second step in improving patch efficiency is to delegate some of the overall work to specialised applications that monitor versioning, ageing and obsolescence across a wide spectrum of known and popular applications.
The second step in improving patch efficiency is to delegate some of the overall work to specialised applications that monitor versioning, ageing and obsolescence across a wide spectrum of known and popular applications.
3. Stay in the sandbox
In many cases, security and currency of applications must be weighed against the specific purpose for which they are used. When seen in context, applications often perform legacy tasks, up to a point where both the application and the underlying operating system need to be decoupled from any further updates.
In practice, ‘sandboxing’ this type of setup may be easier (and quicker) than having to worry about gaps and exposures.
In practice, ‘sandboxing’ this type of setup may be easier (and quicker) than having to worry about gaps and exposures.
4. Use airgaps wisely
Where applications do the job properly (without too many known bugs), much of the patching and updating suggested by suppliers or distributors address either security weaknesses or arcane bugs that may not have any real impact on users.
For example, fixed character set issue in Old Norse language file. Typically, suppliers and distributors tend to bundle this type of patch after a while and present a (fairly major) release or version update.
The fourth step in improving patching and updating is therefore a risk-based game: where applications can be air-gapped for a while, they may work fine until the next major release. If and where this type of use is acceptable, it will significantly reduce the noise of minor patches that seem to appear almost daily.
For example, fixed character set issue in Old Norse language file. Typically, suppliers and distributors tend to bundle this type of patch after a while and present a (fairly major) release or version update.
The fourth step in improving patching and updating is therefore a risk-based game: where applications can be air-gapped for a while, they may work fine until the next major release. If and where this type of use is acceptable, it will significantly reduce the noise of minor patches that seem to appear almost daily.
5. Manage, don’t work
Practical experience has shown that, particularly for mobile and BYOD, traditional patching is constrained by technical (operating system) or legal (supplier branding) limitations.
The last step in improving patching and updating is to shift the focus from central patch management to end-user pull solutions. It is often necessary (and more efficient, anyway) to have the end-user opt into or accept certain modifications to their devices.
In this sense, it is more important to address the way end-users act rather than the patches themselves.
The last step in improving patching and updating is to shift the focus from central patch management to end-user pull solutions. It is often necessary (and more efficient, anyway) to have the end-user opt into or accept certain modifications to their devices.
In this sense, it is more important to address the way end-users act rather than the patches themselves.
Finally, it should be noted that the steps discussed above will certainly bring more efficiency, but they are unlikely to cure the root cause.
More often than not, it is up to the suppliers and distributors to streamline and improve their development and release process, rather than releasing intrinsically weak or bug-ridden interim results.
--- End of Quote ---
