A Simple Effective Patch Process

In light of all the recent attention on patching, having been in the patch industry for more than a decade and working with business, and government in every corner of the globe I feel uniquely qualified to discuss this topic.

The patch process has been made incredibly difficult and complicated by business and well meaning security professionals. Patching does not need to be difficult, it does not need to involve CVE's or risk mitigation strategies. So what should patching involve? Over the years we have developed a very simple approach to patching, that everyone CAN do but most still go down the complex route. I will share these here with everyone, in hope that it will improve your security posture.

We are now seeing business from 100-300 thousand endpoints which have taken these strategies to patch within 7 business days. You too can do this and must do this. You can be at the forefront or drag your feet; being forced to reach this point in the coming days, months or years by your business.


What should you patch?

Everything


When should you patch? 

ASAP


What is the risk if you do nothing?

Broken/compromised systems. Lost/Stolen data/financial impact


What is the risk if we patch?

Broken systems. User disruption.


The process that I have always advocated is done through the following simple process. Ideally performed by a security professional that understands endpoint security, installation, and troubleshooting.

1. Use a patching solution.

2. Aquire the patches into said patching solution.

3. Deploy the ALL applicable, required patches (Critical, Critical 01-05) to 10% of the business based on department.

- Example - HR has 40 systems, deploy to 4 machines within the HR department. Carry this across all business departments.

4. Run for one week to ensure systems are not broken.

5. Deploy patches to remainder of business systems after above testing.

6. Patch deployment to all machines should be completed 48 hours after test week conclusion.

The above process should be applied to servers, workstations, and laptops within the organization.

Should you run into systems which are broken by the patching you will need to troubleshoot and understand what/where the system broke. Once you know this you can easily understand what other departments or applications might be impacted by the patches. 


It's certainly the approach I would take. The risk of not patching and being compromised far out weighs the risk of disrupting due to a needed reboot or application conflict - and in any case, disruption can be minimised with a solid test plan.

To view or add a comment, sign in

Others also viewed

Explore content categories