Once a fairly straightforward exercise, patching in the mobile era has become fraught with complexity.
So you've bitten the bullet, identified your business-critical systems, implemented a staging environment and tested all the patches before deploying on live systems using something like WSUS. No blue screens, everything works, nice and secure – and that should be the end of the story. But what exactly did you patch? The operating system alone may not be enough any more.
Let's assume it's a Microsoft environment. It will be fairly straightforward to patch an operating system, web server, workstation and maybe even some of the desktop applications. But if it's a flavour of Unix, you've got a different and more complex set of update processes to run – and potentially a different support team to coordinate.
You also need to think about mobile workers, particularly those who rarely come in to the office. Those with fast broadband lines at home won't particularly mind chunky updates being auto-deployed. However, if on mobile data, a .Net update being downloaded over the air while trying to sync email on a train will be a real pain. I've been there myself, trying to work out how on earth a one-hour mobile email session resulted in 100MB of traffic!
Unfortunately, as a result of security managers' diligence in patching operating systems, hacker attention has changed tack in recent years.
Increasingly, desktop applications such as Acrobat Reader are gaining attention from hackers, resulting in yet more patching tasks.
Browser exploits have been in vogue for a while, but do you patch the desktop browser? Sure, maybe you manage Internet Explorer, but if you allow use of Firefox and others (often for reasons of improved security), you will need to manage patching these as well.
Similarly, browser plug-ins such as the Flash player may well offer great opportunity for compromise – yet they also happen to be a challenge to patch in themselves.
File-compression software, VPN clients, anti-virus and virtual machine management software have each had vulnerabilities – so they too need attention.
All of the above are solvable, using freeware, bundled or paid-for applications, but half of the problem is identifying and prioritising what to patch, to say nothing of the complexity of patching remote devices.
Patching mobile device operating systems presents yet more problems. My Windows Mobile device comes with ‘Windows Update' apparently, but I've never yet seen an update to retrieve.
As for drivers and firmware, a while back some issues in the Intel wireless chipset drivers led to the ability to remotely compromise a wireless device over the air. Old news, but hardly anyone updated these drivers, as they didn't pop up in the list of ‘critical' operating system patches in Windows Update.
Firmware has been getting some attention from the underworld too. Devices manufactured in the Far East have popped up with back doors at the firmware level. Even big networking vendors have had their products compromised.
We have been playing with some of our own thin client systems recently and found some amusingly simple vulnerabilities. In default config, you get a lovely remote view of another user's desktop, without authentication. This leads on to the problem of patching embedded operating systems. They abound in devices that control our everyday living – installed and forgotten about. They control the air conditioning in the building, the door locks, even the lifts. This has to be the next big move in hacker activity. Even televisions are starting to be found with RJ45 connections for media streaming.
We all know how to patch and we all know how important it is to do patching on a regular basis.
We now need to ensure that we have considered everything that should be patched, consider the risk of each – and prioritise.
My advice would be to design your network along the “defence in depth” principle – that way, if the systems you don't patch are compromised, it's not the end of the world.