Maksim Kabakou - Fotolia
Regularly servicing your infrastructure with software patches is an integral part of keeping systems safe, reliable, supportable and secure. Any company that ignores this is asking for trouble, just like ignoring those worn brake pads on your car. Sooner or later, something will go wrong in an unpatched environment.
While security seems to get the most attention when it comes to patching, do not forget that patching will also keep systems running smoothly. Reliability and uptime are often ignored, plus older software versions quickly go out of support so you might find yourself with the latest and greatest software which is too many patch versions behind to get critical support when you need it.
Know what you’ve got before it needs patching
The biggest issue I come across when doing penetration tests and/or audit work is some piece of deprecated software that clients did not even know was there.
Stating the obvious really, but a patch management regime quickly falls apart if you have no idea what is running on critical machines. Get a software asset list together. Know what is there.
Patching is not just about Microsoft
So software patching’s about leaving Windows Update running, and everything will take care of itself? OK, so you are nearly there if you only use Microsoft servers, workstations, smartphones, telephones, door entry systems, photocopiers… Pretty sure Microsoft made iTunes and Quicktime too, right?
Much as it would like you not to think so, the world is not just Microsoft.
The big culprits are the likes of Apple and Adobe software, given the funky things they do with low-level system drivers. And while Oracle was doing more or less OK in the patching stakes, I reckon it has quadrupled its vulnerability output since acquiring Java.
Who polices the patching police?
It is reasonably well known among the security community that certain automatic update software does not always work. While there is a big green tick on the screen, critical security updates are missing.
So how do you tell automatic patching software is actually working? The trick is quite simple: Do not rely on it. Any update software that comes as part of the software it is trying to update cannot be trusted.
Vulnerability scanners don’t find everything
It’s a good idea to get hold of an independent vulnerability scanner that can scan all of your systems for missing patches en masse. But they’ll only get 99% of the way there. Even less so if assets are not there when you scan them – for example laptops, smartphones and whatever your boss decides to bring in and plug into your network.
Plus scanners time out, they can only support so many threads, and plenty just run out of steam and give up in dynamic environments.
So what works then?
Good question. I think vulnerability scanners are a critical part of your defence here, as they do cover most of the issues above. But how do you know your scanners are working? Who polices the vulnerability scanning police?
This is where the paper trail and audit work comes in. You need a human being to sample machines on a regular basis and compare the latest available vulnerability list with what’s actually running on your machines. We do this all the time in PCI DSS (payment card industry data security standard) audits, and it is really not that difficult, just time-consuming.
So back to square one, you can help yourself by:
- Standardising your environment. It’s easier to secure one standard build than a hundred different builds.
- Creating an approved software list, with hopefully not a lot on it. It’s easier to keep on top of patching a controlled list.
- Learning the difference between vulnerabilities and exploits. Sign up to a Cert. Gain intelligence by being aware of what might be vulnerable, before some kid releases a zero day exploit. You might want to put more focus on systems that have a few hundred vulnerabilities that haven’t been exploited yet, as opposed to systems that nobody’s managed to hack for the past few years.
- Just saying no. If management want to install this funky new software and you’ve no idea of its heritage, sit them down, get them a cup of tea, and explain how they are about to disrupt your finely balanced software ecosystem. After all, nine times out of 10, changes are what cause security problems.
Of course there’s a balance to be had between usability, security, risk and profits, and it is a tough nut to crack, but if you’re in a scenario with hundreds of different build variations and only 10 employees, then something has probably gone wrong that needs fixing – urgently. It’s not going to go away.
Tim Holman is CEO at security consultancy 2-sec.