Blog Software Patching – A Best Practice Guide

The problem with software

Software’s great; the Internet is built on it, businesses rely on it, it allows us to achieve incredible things and without it the world would be much poorer. But as with most wonderful things, there is a dark side.

Although a piece of software is written to perform a specific task, there is a danger that an unscrupulous person can make it do something slightly different if they take an action that the software writer wasn’t expecting when they wrote the code. For example, this could be sending it data that it wasn’t written to cope with, or fooling it into believing something that’s untrue.

If someone spots something like this that could be done to a piece of software, it’s termed a vulnerability and when someone writes another piece of code to take advantage of that vulnerability it’s called an exploit.

How do we find vulnerabilities?

These things called vulnerabilities usually aren’t obvious when the code is written, otherwise the author would fix them there and then (although some would question this as it’s not the author who takes the hit when a vulnerability is found and exploited). So how are they found?

Hopefully the software writer will use best practice guidance to write code that has as few vulnerabilities in it as possible, for example OWASP, but after this the next stop is testing. Security testing has come a long way since the early days and it’s now possible to spot and fix many vulnerabilities that otherwise would have slipped through.

Once the software is released, there are a number of groups that have an interest in finding vulnerabilities in it. The first is the software company, who may come across issues whilst writing the next version for example. Second is the community of cybersecurity researchers, who look for vulnerabilities and tell the developer about them when they find them (often in return for a “bug bounty”). But third is the problem group, who look for vulnerabilities and weaponize them into exploits for use in attacks such as ransomware and other extortion activities.

You can see a list of vulnerabilities that have been found in various types of software in several publicly available databases, including at NIST. However, the ones found by the bad guys won’t be on the list because they keep them to themselves; when a “secret” vulnerability is used for the first time it’s termed a “zero-day exploit” and these can be worth a lot of money.

What is software patching?

When a software vendor becomes aware of a vulnerability, it’s usually in their interests to fix it by changing the code so that it no longer applies. They will issue sets of such fixes to their customers as “patches”, either on a regular basis (maybe monthly as in the case of Microsoft) or, if the fix is urgent, as special releases; in most cases, vendors do both. All the customer then has to do is apply the patches to their systems, and the vulnerabilities are closed.

So that’s great – the problem is solved isn’t it? Well, not quite.

Some challenges of software patching

There are a number of potential issues that mean that software patching isn’t always as straightforward as everyone would like.

Firstly, the vendor may not issue a patch at all even though it knows about the vulnerability. Commercial pressures may mean that resources are not available quickly to fix the code, and there are many cases of researchers having to go public with vulnerabilities they have found (and told the vendor about) because the vendor hasn’t fixed them within a reasonable period of time.

Secondly, there have been cases where the patches have broken something in the software, and a follow-up patch needs to be issued to fix the issues.

A further issue is one of volume and logistics; if you have many servers and clients with many types of software at differing version levels, then patching can become a major exercise that has to be repeated on a regular basis just to keep up.

Most worrying of all is a recent trend towards supply chain hacks where malicious code has been inserted into vendor updates; Solar Winds is the best known of these in recent times, but no-one knows how many others there may have been. If we get to a point where you can’t trust the patches, where do we go from there?

Why is software patching important?

The above challenges notwithstanding, software patching on a regular basis is recognised to be one of the most effective measures you can take to protect your organization against cybersecurity threats. Hackers are constantly on the lookout for software that is behind on patching and are ready and willing to exploit these as soon as they find them. If you don’t patch regularly, you are leaving the door open and setting yourself up as a target in a very frightening way.

So you know you need to patch, but how can you make the process as painless and effective as possible?

Tip #1 - Only use patchable software

If you’re using software that is unsupported or the vendor doesn’t issue patches for, then it really needs to go. Be brutal.

Tip #2 - Invest in some patching software

There are some great software tools out there that will automate your patching for you. They will find out what you have, download the patches for it and apply them while you get on with the day job. Some are not cheap, but may still be worth the investment.

Tip #3 - Know what software you have

Whether you have some patching software or not, you still need to have an accurate idea of the software and versions that exist throughout your IT estate. If you don’t know about it, it won’t get patched, and that’s a risk.

Tip #4 - Prioritise your Internet-facing servers

If you’re going to get hacked, chances are they will come in through the Internet. Make doubly sure that any servers that are accessible from the big wide world are patched to the hilt.

Tip #5 - Scan for vulnerabilities

Even if you’re happy about your patching approach, you should still scan your infrastructure for vulnerabilities. For Internet-facing kit, pay for a service that scans frequently because even if you’re not scanning, the bad guys will be.

Tip #6 - Test where you can

If it’s practical, and if you have servers that you really can’t afford to be down, then test patches before they are applied. Put them onto a non-critical machine of the same type if you don’t have a dedicated test server.

Tip #7 - Check the patches

Just to be sure, validate the patches after downloading them so that you know they are genuine. They may be digitally signed to help you with this.

Tip #8 - Pay attention to urgency

Not all patches are the same. Prioritise those that are security-related or flagged by the vendor as critical. Time is of the essence.

Final words

Software patching isn’t always easy, but it is necessary. Until the software industry comes up with a way to make code bulletproof it is here to stay. Although patching itself isn’t a silver bullet and has its own issues, it’s currently the best we’ve got.

Happy patching!

More ISO27001 Resources

CertiKit is a provider of ISO toolkits, consultancy and internal auditing services, and has helped more than 4000 organizations worldwide with their compliance.

For more guidance on implementing the ISO27001:2022 standard, we’ve put together a list of our best free resources including video guides, blogs and downloadable documents.

Free ISO27001 Resources