Patch management, an imperative for corporate security

“2021, the record year for zero day vulnerabilities”. That’s what Le Monde Informatique headlined in September 2021. It wasn’t even the end of the year. Zero-day vulnerabilities are inherent vulnerabilities in software or products marketed and used by businesses. Unfortunately, this is a trend that should continue for the next few months.

As for vulnerabilities of all types, more than 23,000 are publicly reported throughout the year. This is a large volume that few companies can support by ensuring the deployment of updates or patches.

CIOs need to be extra vigilant not to compromise data and the smooth running of the business. The development of hybrid work weakens the security of your IT environment.

To avoid intrusions, theft, data encryption or ransom demands, companies have every interest in implementing a solid and sustainable patching policy. When we know that it takes more than 100 days on average between the release of a security patch and the deployment by the company, there is still a long way to go.

In this article, we’ll walk you through the ideal process developed by Wixalia to manage patching in your business. This is more commonly called patch management.

Patch management is nothing more than a process that must be well thought out and well executed. Lack of rigor on the part of the entire IT team at this level can compromise the security of the company. But before we talk about the process itself, there are several things you need to bring together.

First of all, the company must have a complete and up-to-date inventory of its computer equipment. This concerns the list of all IT equipment but also all the nesting between the components. What equipment is your switch connected to in Office A? Is it connected to another switch?

Your network topology is defined in two ways:

• how your equipment is interconnected and its spatial location (physical topology).
• how data flows through communication lines (logical topology).

While the list of equipment is generally mastered by companies, the interaction between the latter and the management of flows is often more nebulous.

And yet, this functional mapping is the basis of the impact analysis and the criticality of an intervention as part of the deployment of a patch. How to determine the disruptions caused during an intervention if the mapping of your IT equipment is non-existent or incomplete?

In order not to seriously disrupt the business teams and the business, it is advisable to give advance notice of a reboot or a period of unavailability. To do this, it is necessary to know which equipment, which scope and which software will be impacted.

Poor knowledge of its mapping can lead to :

• a financial loss for the company
• a loss of confidence among customers and a loss of reputation
• social tension among your employees

If today, service interruptions are often poorly controlled within companies, we would like to draw your attention to the prerequisites to be put in place to improve yourself.

Nowadays, everyone swears by automation. Patch management is not spared. Most software vendors offer update automation so their customers save time.

For open source applications, automated patch management helps ensure that asset inventories are updated as soon as possible. But in other cases, it is risky to blindly trust the software publisher for example.

Remember early 2020: Microsoft is rolling out update KB4532693 that caused some users to disappear from their files put on the desktop and reset their “Start” menu and taskbar. The publisher has set up a temporary solution while waiting for the new update.

The consequences of such an error, even temporary, can be significant for users and companies.

At Wixalia, we recommend that you minimize automatic updates in order to assess the impact on your business. If the patch affects a critical part of your business and its deployment does not go as planned, it may be better to wait until it is deployed on a large scale by the publisher and thus ensure its stability.

The right approach to patch management follows these steps:

1. Wait a bit and follow the standard policy (unless the CISO triggers a force majeure case because the risk is too high to follow the usual cycle)
2. Deploy the patch to a non-production environment (a replica of your system on a small scale) and perform non-regression testing
3. Deploy on a test population (10 key people representative of the different activities) then wait a period to observe the possible impacts
4. If everything has gone well so far, it’s time to deploy on a large scale.
5. Finally, perform an automated or manual reboot

Whatever the situation, it is important to assess the balance of benefits and risks before each operation.

Deploying a patch itself is not difficult. What is more is the management of procedures allowing it to be done under the best conditions. Patch management is fully in line with change management. And this is the most important issue for the CIO and his team.

The ITIL method, which is widely used throughout the world, concerns the management of IT services. It is a global approach that takes into account all business services (and not only infrastructure services). The goal? To satisfy the customer’s (even internal) requirements and the service level.

ITIL processes are efficient and adaptable while relying on a model that itself evolves over time to keep up with market developments and new practices.

In concrete terms, ITIL processes are a collection of best practices aimed at improving the management of IT systems (ITSM). They enable information systems to be organised efficiently while putting users at the centre of the action. By optimising the management of IT services, teams save time, ensure better traceability and a complete follow-up of their actions.

Finally, ITIL processes place activities in a continuous improvement approach that increases the overall quality of the IT department and therefore user satisfaction..

In this process, a change sheet is created as part of each patch deployment. This document answers the big questions: what, why, when, how long, who to inform… It is submitted to the change committee which is able to judge its quality and relevance, made up of representatives of the IT team but also business experts.

During the execution of the update, it is good practice to create a maintenance page with a clear and precise message to inform users on a web application for example. It is important to warn the supervision teams to prevent the triggering of level 1 procedures when an anomaly is seen.

Finally, it’s easy to forget to schedule a service disruption to your customers. Still, it can cost you dearly if you exceed the time set out in your contract. If this parameter is written in black and white in your procedures, you will avoid making the odd.