7 Steps For Proper Patch Management Process

Patch Management Process

At the wake of the Intel’s Microarchitectural Data Sampling flaws (MDS), data centers that depend on Intel microprocessors have their system administrators are hard at work in figuring out how to roll-out the mitigation patches timely, effectively and efficiently. Unlike a typical patch management process, mitigating MDS is not an easy undertaking, given that proof-of-concept code is available publicly and can be weaponized anytime. And since MDS is a hardware flaw, the corrective action is penalized by lower performance, as much as 40% with Intel’s Hyperthreading disabled, according to Apple.

The biggest impact will not felt by end-users, but by the enterprise, most especially server farms and cloud-service providers who use Intel processors (90% of the market share). In effect, full implementation of mitigation means that the machine’s value decreases significantly since it can only provide a portion of its expected overall performance. Luckily, AMD and ARM-based processors are not affected, a much smaller number of data centers use them and are not affected by the MDS flaws by default.

Of course, the patch management process may vary from company-to-company, and for case-to-case basis. A firm that requires a 24/7 machine for a specific critical task may remain to be unpatched for MDS if it is a stand-alone air-gapped (not connected to the public Internet) computer. Meanwhile, a machine that has a public interface requires immediate installation of mitigation patches as supplied by Intel, Microsoft, Apple, and Linux distribution providers.

Here in hackercombat.com, we provide some tips in rolling-out an effective patch management process that has minimal impact on employee productivity without compromising IT security:

1. Build/update corporate computing inventory

Day 1 of company operations, a comprehensive inventory of all computing devices should exist. However, in the real world, it is not always the case, in some companies having a complete inventory may even be an afterthought. In the case of MDS mitigations, AMD and ARM machines are not affected, a comprehensive inventory will show the statistics how many Intel, AMD and ARM machines are currently being used in the organization. This gives the implementing team a baseline on how many machines are involved in the process of patch management software, giving them an idea of how long the procedure of updates will last.

2. Establish a list of machines that fully require the patches

Not all machines affected by a flaw or an exploit needs to be patched. Yes, you heard it right, we are advocating for a reasonable level of patch management process, not a perfect one. For the case of MDS mitigations, machines that are air-gapped need not be updated. These non-networked computers perform a specific task, and never used for any other auxiliary purpose. Non-networked computers are usually secured physically, and there is no way to remotely access them in order for a 3rd party to use a weaponized flaw against the machine.

3. Define a test machine for simulating full roll-out of patches

Installation of patches is the quickest part of any patch management process, however, rolling the patches to all the qualified machines at the same time only invites further trouble down the line. Combination of application software, drivers and other system updates from the past can complicate the patch management process. There will be times that a specific machine will not behave as expected after the installation of a patch in combination with another installed software or driver in the system. In these instances, the conflict can be determined early if the patches are deployed to test machines first or only for a limited sample of production machines.

4. Backup critical and user data before installing the patches

With the availability of cloud-backup, lower cost of hard drives and other consumer storage devices there is no valid alibi not to have a credible backup strategy. System backup for the affected machines should be implemented before rolling-out the patch management process. This way, if trouble comes such as system corruption occurs, the affected system can be restored from the backup painlessly instead of rebuilding it from scratch.

5. IT team to enforce full monitoring of patched machines for the next 24-hours

The first 24-hours after the patch management process implementation is crucial for monitoring. Once staff members start to use the patched machines again, the problem may be reported, which requires full documentation which is helpful in formulating a quick workaround or even a permanent fix at a later date.

6. Perform reconfiguration for those that failed to pass the quality test after the patch installation

A failed rolled-out does not mean leaving the machine unmitigated. There are times a small tweak is all that is needed in order to fix the problem after the patch management process. The procedure may require a Windows Registry edit, a knowledgebase instruction from the software vendor or change of commodity hardware such as a new network card.

7. Perform step 1