Cyber Essentials – patch management
In the UK, the National Cyber Security Centre (NCSC) runs an information assurance scheme called Cyber Essentials. Our blog post series looks at each of the framework’s five controls and offers practical hints and tips on how you can meet the security requirements and obtain Cyber Essentials certification., This week we look at patch management.
Cyber Essentials – advice on how to keep your devices and software up to date
This post, the sixth and final post in our Cyber Essentials series, focuses on the Cyber Essentials control “keep your devices and software up to date”. Posts 1-5 can be viewed via these links: Post 1, Post 2, Post 3, Post 4 and Post 5. Patch management, applying the latest vendor patches, is one of the most crucial security hygiene activities organisations use to keep their systems protected from viruses and hacking.
If a known vulnerability can be exploited by a hacker to gain access to a computer or bypass security to access information, it’s almost certain that it will be. When a new vulnerability is discovered, a race begins between vendors and hackers. Vendors are trying to fix the problem, which results in a patch being issued, while hackers develop exploits, which are applications that leverage the vulnerability to gain an advantage over the target system. Most of the time, if the security research marketplace is working as it should, when a vulnerability is discovered, it is commonly reported to the vendor well before it’s made public, to give the vendor time to manufacture and test the patch. Once the patch is ready, the researchers release details of their discovery, and point to the vendor patch as the way to address the problem. No situation is perfect, however, and plans often don’t work out.
Why is patch management harder than it sounds?
Microsoft and Apple have robust patch management built into both desktop and server operating systems. Windows 10 also offers several options for keeping devices up to date, and they have extended patching to most of their software application suites too, hence why Office frequently suggests there is an update requiring an installation.
Updates can be applied automatically, which is a great way to ensure you stay current and vulnerabilities are addressed as soon as the fix is available. However, some IT managers switch off auto-update because it’s been known in the past to cause outages, hence the service management team want to first test all updates prior to rolling them out to the business. On the surface of things, this is a good approach, yet it doesn’t consider the risks of delay.
The number of days a system remains at risk when a critical patch has not been applied is a decent measurement of how exposed your organisation is. Each day that passes, the likelihood of the systems being compromised goes up. If you normally apply patches on a monthly cycle, even when critical patches come out, every computer you own will have up to 30 days of exposure. The question you need to answer as a business owner is, is this exposure to ransomware, data theft, denial of service, or critical system compromise greater than the risks relating to rolling out the patch as soon as it’s released? A 30-day patch cycle is really an overt statement of risk tolerance, with specific cost and business value ramifications, tied to the business impact of a compromise compared to the impact of some system downtime (based on a failed installation).
Managing system retirement
We’ve all heard the term ‘sweat the asset’, which means try to get as much life out of a computer system as possible and don’t upgrade before necessary. Yet the advice from Cyber Essentials points out that, “When the manufacturer no longer supports your hardware or software and new updates cease to appear, you should consider a modern replacement.” Again, this is a risk management exercise, since the longer a system has no official support from the vendor, the more likely the discovery of a vulnerability that never gets a vendor patch.
As a component of your IT strategy, you should have a management plan for equipment obsolescence, which includes upgrading PCs, laptops, mobile devices, servers and network equipment when vendor support ends. Furthermore, managed obsolescence should include software, since software manufacturers also use retiring of support to get customers to upgrade to the latest version.
Asset management is the primary process managed obsolescence falls within, since assets have a lifespan and budgets should be assigned based on those lifespans, thus you are always forecasting when the next ICT spending activity is required for upgrade and replacements (thus, no surprises for the board).
In larger organisations, there are several discrete roles within the business that should be included in the vulnerability and patch management plan. In smaller organisations, the roles still exist, but may be consolidated and managed by one team. Nevertheless, the following list shows the stakeholders that should be included in patch management planning, so the right people in the business can support the process:
- Service desk
- IT operations
- Engineering, including desktop, server and network management
- Patch assessment team (sometimes called vulnerability management)
- Software developers
- Governance, risk and compliance
The service desk handles user interactions and may need to issue downtime notices to users when a reboot or other business interruption occurs. IT operations usually deploy patches, while the engineering teams would assess their impact on their production systems and look at how the updates would work. Patch assessment (vulnerability management) is a crucial aspect of this process, since their role is to assess the patch implications for their business. Not all critical patches issued by a vendor will require a critical patch response from the business. For example, a critical patch for an operating system feature you don’t use does not require an immediate response, if that feature is disabled.
Patch everything, patch now
The ideal situation is that you patch everything as soon as fixes are available. The problem with this is that you may not know a patch is available, especially if the software vendor doesn’t proactively notify customers. It pays to have a catch-all patch management process set up within your service management team to check the vendor websites to see if any new patches have been released. Many platforms don’t have auto-update capability, consequently this manual process becomes even more important.