Bite size Cyber: #1 Patching

Are you new to cyber security, and / or is it something you’ve been asked to look at for your organisation? Are you struggling to find sensible advice which is practical and pragmatic? Are you looking for some simple steps which you can follow to help get the ball rolling? Then this short series of articles is for you.

The intention is to provide some bite size nuggets of information which you can apply and which will rapidly help secure your organisation, whether its a company of 2 people or 200 (or 20,000 for that matter).

We’ll also look at other sources of information along the way, which you can read in your own time and which will help provide more context to the topics covered here.

Oh, and just as an aside, elsewhere on this site you’ll find a handy A-Z of terms, so if there’s something mentioned which you don’t know or understand, check that out. If you can’t find what you need there, please do drop me a line.

What you need to know

Let’s start with one of the basic elements when protecting systems, which is patching. When you think about a car or bike tyre, you know that occasionally they get holes in them, and the way they get fixed is by applying a patch. This is where the term patching comes from.

All software is likely to have holes in it which attackers can use to target systems. These holes are called vulnerabilities, and some are apparent from the day the software is written, and some are undiscovered for months or years. Some of these vulnerabilities are related to making the software work properly, and some are related to security issues. A software patch is a piece of code which removes the vulnerability.

Many vendors provide patches to their software on a regular basis. For example, Microsoft typically issue their patches on the second Tuesday of every month: in the industry this is known as “Patch Tuesday”. Other vendors have a different release schedule, and you can easily find out when they are.

You also need to be aware that when patches are released the manufacturer typically gives an indication of the urgency, severity or priority with which they need to be applied. Different vendors have different terms for these patches.

It’s worth remembering that many of us have mobile devices like smartphones and tablets which tell us when patches are ready to be installed. Make sure that you apply those patches when prompted.

What you need to do

  1. Check what software you have, and find out when patches are released.
  2. Ensure that all devices in your organisation have the latest patches installed. Don’t forget to include servers, mobile devices, firewalls and other network devices in the list of equipment to be patched.
  3. Develop a plan – and implement it – to download patches when they are released.
    1. Ensure that the plan includes a step to test the patches on a subset of the machines in your organisation before rolling them out to all machines.
  4. Develop a patch schedule and stick to it. Bear in mind that after a patch has been applied computers may need to be rebooted. After the reboot, check that the patch has been installed effectively.
  5. Install the patches in a timely manner. For example, urgent patches should be applied as soon as possible, but low priority patches can be applied at a more leisurely pace.

Further reading

There are a number of articles on patching around this site, but you may also want to read some “official” guidance. I always recommend the UK Government’s 10 Steps to Cyber Security as a good source of independent, industry standard, information.

You may even decide that, when the time is right, you want to put your organisation through formal security certification and the UK Government’s Cyber Essentials scheme is a good place to start with that.

Patching – what’s all the fuss about?

I suppose this falls under Security 101, one of the most basic things we’re all encouraged to do with our technology, but there’s always a reason to postpone it:

  • My machine slows down while it’s downloading the latest patches
  • I’m worried that things won’t work afterwards
  • I keep having to reboot my machine, sometimes several times during one set of updates
  • I’m busy just now, can I not just do it later?
  • I don’t use the Internet much, so my device can’t be infected
  • I’m not using Microsoft, so there’s no need to patch
  • ….and, well, you know how it goes on….

I’m sure you’ve got your own versions of these, but the point is that these are all just excuses for something that should just be part of your normal experience – in my opinion.

Should we patch absolutely everything? I.e. should we install all updates for all products as soon as they’re available? No, I don’t think so. We should base our patching strategy on a risk assessment. If you find out about a patch for one software programme – let’s say Microsoft PowerPoint – but don’t have PowerPoint on your device, do you need to apply that patch? Not if it only addresses vulnerabilities in PowerPoint, as your device doesn’t have that vulnerability. But if the patch includes other packages which you do have installed eg Excel, then yes, you should.

Why am I picking on Microsoft? Just in order to use program names that we’re most likely to be familiar with. The same principles apply equally to other vendors and other software packages. Software has vulnerabilities, it’s inevitable. If there are none on the day it is released someone somewhere will find some soon afterwards. And the more valuable the data you access through the software, the more likely someone is try to create an exploit for that vulnerability.

In my opinion, you should patch regularly i.e. keep patches up to date. Apart from anything else, this lessens the amount of time spent downloading updates, as you’re keeping on top of things (in many respects, the same goes for antivirus updates too). Patch what you have to, but eg if the patch is for a Mac and you’re using Linux, why apply a Mac patch unless the patch also applies to Linux devices.

Not using the Internet often is no protection either. The only truly secure device (from Internet attack anyway) is one which does not have any form of external interface (wifi, wired, serial cable, whatever) and which is never connected. Some well known legitimate websites have been targeted and have had malicious code embedded in them, infecting users who are only browsing (because no software is totally secure, right?). Botnets are out there looking (in an automated way) for vulernable machines, so you only need to connect once to run the risk of infection. It’s a bit like contraception – if you don’t ever have sex, you’re unlikely to get pregnant, but do it just once without any form of protection and pregnancy is a very real risk.

If you’re only looking at your personal / home PC / laptop / tablet etc, then you’re unlikely to have a test environment. This is the best place to try out new patches, but if you’re a home user then you probably don’t have the luxury of testing things there. In any event, its notoriously difficult to configure your test environment to exactly match your real, live environment, down to version numbers of DLLs and other components, so you’re probably just testing in a representation of your live environment and there will still be some risk when you deploy for real. So what should you do?

This is where having a good, robust (and tested) backup regime comes in. More on that in a future post, so watch this space…