updates-mini-guide

Efficient updates management: Mini practical guide

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.

The importance of updates

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.

Steps to a good update management plan

1. Asset inventory

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.

2. Prioritization

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).

3. Update schedule

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.

4. Tests

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.

5. Back-up

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).

6. Review and notification

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.

7. 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.

8. Maintenance and ongoing monitoring

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.

Conclusion

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:

  1. become aware of the risk of poor update management
  2. is involved in the process. We tend to forget it, but the person in charge is the company director in the event of a cyber attack.
  3. release budget if necessary to enable the IT team to do its job properly.

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.

Sources/Further information:

Peace ✌️

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!!! 😀

    Why Yack?

    First, for those of you who don't know, the yak is an animal. The energy it radiates (chill with its toupee, but we wouldn't want to piss it off with its horns...) represents us well, and the nerdiest among you might see the little nod to Linux 😉. Of course, Yack's resemblance to Hack is no mere coincidence. It's also a short, punchy name that, once again, sounds like us. Finally, it's a word that earns you 24 points in Scrabble (hello Office de la langue française). Why did you choose .one? In offensive security, all it takes is one attack..."
    A little more about us

    "Pourquoi Yack?

    First, pour ceux qui ne le savent pas, le yack est un animal. L'énergie qu'il dégage (chill avec son toupet, mais on ne voudrait pas l'énerver avec ses cornes...) nous représente bien, et les plus nerds d'entre vous verront peut-être le petit clin d'œil à Linux 😉. Bien sûr, la ressemblance de Yack avec Hack n'est pas une simple coïncidence. C'est aussi un nom court, qui punch, et qui encore une fois, nous ressemble. Enfin, c'est un mot qui te rapporte 24 points au scrabble (bonjour office de la langue française). Pourquoi avoir choisi .one? En sécurité offensive, il suffit d'une (one) attaque..."
    Un peu plus sur nous