Maksim Kabakou - Fotolia

Security Think Tank: Security patching an essential element of outsourcing contracts

What strategies can companies adopt to keep up and deal with the huge volume of software updates they face?

In past articles I have written of the InfoSec fundamental of keeping systems up to date, writes Peter Wenham. By this I meant ensuring that all software is current and supported by the manufacturer and that security patching is up to date. That is easy to say (and write) – but the reality is that, for many companies, that is not an easy task. My experience is that quite a few companies fail in this – some quite spectacularly. 

For small organisations with only a handful of PCs (and possibly a networked printer or local to the PC printing) on a simple network connected to the internet via a router/firewall, the issue should not be that big, because most modern operating systems (OSs) and major applications (office suites, Adobe, AV etc.) can automatically get updates. 

However some applications – think legacy – might not have an automatic update facility and it is advisable for any company (micro or not) to create an asset register (list) of all software running on each of their PCs and where applicable servers, and should also note how each product is updated (as well as when purchased, license numbers, supplier, manufacturer, web site for updates). Such an asset register is a required control in ISO27001. In a micro company a person should be designated to check monthly on manufacturers’ sites of those products that do not automatically update and undertake updating as necessary. 

Larger companies may have in-house IT (servers, printers, e-mail, storage area networks) or outsourced IT in a cloud or hosting company, or a mixture. In the case where the IT management and maintenance is outsourced – and irrespective of whether the actual IT hardware is in-house or part of a cloud or hosted service – the contract covering support should stipulate that any and all software is effectively managed and maintained at a current level of manufacturers' support and is security patched up to date. Some mechanism for auditing compliance should be built into the contract, and any audit – particularly where the audit function is itself outsourced – should be accompanied by a required IT security health check report (ITSHC). The ITSHC should be carried out at least annually and preferably additionally supported by quarterly internet-only checks. The ITSHC should cover the internal network as well as testing from the internet; internal testing should identify products with out-of-date patching as a security issue.

Scan to identify patch deficits

Where IT is maintained in-house, automated vulnerability scanning or audit tools can be used on a regular basis to identify what software requires patching – but note that some products, particularly bespoke ones, may not show up on a scan or give patch information. For Microsoft environments, Windows Server Update Services (WSUS) can be used to ensure that Microsoft products are kept up to date, but where a company adopts a "patch and be dammed" approach – all patches released automatically from WSUS – then this should only be done where there is a tested, viable backup process, that runs nightly, and there is a user service level agreement (SLA) in place to cover time lost due to having to back-out a system following an automated patch update failure. In environments with a large number of user devices, the adoption of thin client and terminal services approach where a standard image is deployed to a user at log-on time, can dramatically ease the patch burden, as only one image needs to be updated (with the previous image held as a fall-back/backup). 

Where there are a large number of servers, the use of virtualisation and high-end management products – such as MS System Centre or VM vCenter – can ease the patch burden, by fully automating server patching. Audit trails provided by these tools also help with ISO27001 compliance reporting. Where legacy or bespoke software is in use, you need to test any patches prior to deployment. These tools will allow a server to be cloned and, once cloned, patched, tested and deployed with the previous image stored for backup.

Peter Wenham is a committee member of the BCS Security Forum strategic panel and director of information assurance consultancy Trusted Management.


Read more on IT risk management