This article has originally been written in french and then translated with tools. The translation should be on point, but please forgive us if some parts are not perfect.
Update management remains an irritant for many IT teams in the cybersecurity management process. “Upgrading” is one of the most frequent recommendations following an intrusion test or vulnerability scan.
While these are easy recommendations to implement on paper, ensuring that all your company’s equipment is up to date, all the time, missing nothing, avoiding the potential negative consequences of certain updates on operations, etc., are major challenges (and generate a lot of headaches…).
We’re not even talking here about updates that are impossible to make, because the system in question doesn’t support new versions. For these, unless you can invest hundreds of thousands of dollars in new equipment, you need to think of a different strategy for dealing with the problem.
Unfortunately, unapplied patches are among the most common causes of domain compromise. It’s time to take the bull by the horns and address the problem.
Updates, or patches, are designed to correct problems in existing software, including vulnerabilities that can be exploited by cybercriminals. By neglecting these updates, you leave an open door to attackers who have the tools and knowledge to penetrate your systems.
When a vulnerability is discovered on a product, the information is massively relayed and cybercriminals seek to exploit it. Very often, scripts are created (and distributed) to exploit these vulnerabilities. Bots even go in search of this flaw to compromise as many systems as possible.
This is why, as soon as a 0-day vulnerability is discovered, manufacturers race against time to patch their systems before the vulnerability is exploited on a massive scale.
Saying “update your systems” is really limited advice, so we’re going to outline a good update management plan.
The first step to effective update management is to understand what you have. This involves cataloguing all the devices, servers, routers, systems and software that are part of your network. This inventory must be regularly updated to reflect reality as closely as possible. This will prevent you from forgetting an important update for the simple reason that the device to be updated was unknown to the pack.
Ideally, this inventory should include an assessment of each device’s operating system, key applications and firmware, and reflect how a change to one device could affect overall operations.
Not all systems are created equal when it comes to security risks. Some, like systems containing sensitive data, should be given priority for updates. It’s crucial to assess and rank your systems according to risk. As the IT department is often overwhelmed, this helps to put efforts in the right place if action needs to be prioritized. Updates to critical systems should be at the top of the list (much higher than Bertrand who forgot his password).
A good structure helps to ensure consistency and avoid oversights, especially when the IT department is moving at 300 km/hour. Determine critical patch criteria and preferred patch schedules. Although, ideally, every system should be patched with the latest versions, this is not always realistic.
Management and functional experts need to work together to determine which patches are most critical (no, the responsibility for updates doesn’t lie solely with IT friends). Many important operating systems and software packages can be configured to update automatically.
Of course, this won’t handle emergency updates (released after a 0-day, for example) since unfortunately we’re not yet able to predict when vulnerabilities will be released* 🤓 , but it will keep updates at the heart of your IT processes.
Many people are afraid to apply updates for fear that they will affect the smooth running of the system (legit).
To avoid this problem, it’s best to create a test environment that replicates the operational environment as closely as possible; for example, build a microcosm of your company’s intranet. It should represent every device that the inventory has determined to be mission-critical. Use this sandbox to determine whether a new software or firmware patch could impact operations, or even lead to loss of data or access to key systems.
If the test environment is not an option, test the patch on a small sample of systems to check for adverse effects.
Before deploying a patch, you need to set up systems for backing up server and device information. This is essential in case systems need to be restored to their previous state if unforeseen problems arise during or after patching. It can save a lot of trouble (and it solves the problem of reluctance to update, since you can go back to the way things were in the event of a problem).
System owners and functional managers should review the potential impact of patches and decide whether and/or when to implement them. All those likely to be affected should be informed about the implementation of patches and how to report adverse effects. Good communication will save you a lot of trouble during deployment.
Deploy updates outside peak hours, if possible, to reduce operational risk. If the patch is an emergency fix, we agree that it should be deployed as quickly as possible.
After deployment, it’s important to check that updates have been correctly installed and are working as expected.
Overall, it’s important that roles and responsibilities are clearly defined, and update management is no exception.
The Equifax incident in 2017 is an excellent example, as CEO Richard Smith blamed his CIO for not forwarding the vulnerability email to the IT team, who had to apply the patch manually. 400 Equifax employees had received this e-mail, as the update management process did not require the CIO to take action on this type of message. As is often the case when roles and responsibilities are unclear, no one acted on the assumption that someone else would. We all know the unfortunate end of the story.
As with any high-risk project, a project manager needs to be identified and accountable to senior management for changes, concerns and progress. Documentation is essential to mitigating risk, and must be reviewed regularly to take account of changes in threat vectors and actors.
Implementing this process remains a long and complex process, especially in a context where there aren’t enough IT staff in the company to take on all their responsibilities. That said, it remains a priority, given the potential impact it can have on the company.
It’s important to raise this point with management teams, so that they:
If necessary, a vulnerability scan of the internal network will reveal the thousands of identified vulnerabilities. This usually helps you understand just how critical the issue is.
Cyndie & Nicholas
anecdote: we’ve already seen in the list of selection criteria for a vulnerability scan tool that it should provide a list of present and future vulnerabilities. 😅😂 We had a good laugh, but if anyone actually finds a tool that does this, please contact us!!! 😀