It may seem obvious that you should implement updates when prompted, but it isn’t always easy. Updating your own Windows laptop when you get an update alert is simple and straightforward—unless, of course, you are in the middle of a client presentation when an update starts.
But if you are doing much more than that, it takes both skill and time, and therefore money, and careful planning.
It may require some downtime for crucial business systems, and therefore will incur cost and inconvenience.
Also, for some companies, there are devices out in the field that might need to be recalled and brought in for patching, or which may require a field-trip for updates. Either of these requirements could delay updates.
You need to know what you have, in order to know what needs to be patched. For a small company, this might be simple, but for a large organisation, maintaining an up-to-date list of assets can be difficult. If there are a large number of assets to be updated, patching can become a fulltime job.
Some software is very hard to patch because the code can’t be modified, or can’t be modified quickly. This could be for one or more of many reasons, such as
- The problem isn’t in the code that you own, for example, it is in a commercial application. You have to wait for an official patch to be released.
- The problem isn’t on assets that you own, though you do use them, so you are dependent on someone else doing the updates. These third parties might be vendors— or they might be employees with personal devices used for work, under your Bring Your Own Device (BYOD) policy.
- Fixes might take time to implement, because of the testing time required to make sure that making such a change doesn’t negatively impact anything else.
- Fixes might be prohibitively expensive: perhaps it was poorly documented, or extremely complex, and you no longer have the skills in-house to implement a fix—or perhaps you just don’t have the budget.
- The fix might be required to legacy code in an application: perhaps the vendor has gone out of business, or that version is no longer supported.
- Updates to your asset would require it to be recertified, which would take it out of use for some time.
- You are required to maintain an asset as is pending investigations of some kind.
- Updates to one asset require an updated version of another—but that one can’t be updated for one of the reasons listed.
- You are running embedded systems, for which you may not have the source code.
- Your software is so old that patches are no longer available and/or it won’t support newer versions of software.
- Your asset has no free memory to install a patch.
- There are known bugs in an update that would adversely impact your system.
Sometimes patching requires a reboot to take effect: this isn’t always as straightforward as ‘turning it off and on again’, particularly if this is a production machine running 24/7.
And sometimes patching can fail. The patch installation may fail, or it might cause unexpected operational issues—particularly in complex systems —and need to be uninstalled, or patched in turn. Rolling back to the previous version of the system also adds time and costs to the process.
However, postponing patching gives attackers more time to take advantage of the vulnerability in your
systems. If a patch fixes a security issue, it is likely that an attacker knows about the problem already. Perhaps by reverse engineering the patch to establish the issue with the code.