3 Patching Strategies to Help Improve Security Hygiene for the New Year

Patching is a boring thing to do, but its an imperative practice if you want to avoid being the next security breach headline.   With so much at stake why is it still so hard for companies to keep up? Reasons for bad patch maintenance include don’t have time, afraid it will break the applications, and we can’t delay the release of the newest features.   These are all valid reasons, however, the solution is to work with these requirements to develop a good patching strategy. Patching is rarely a technical problem, rather a commitment and coordination effort of executives, infrastructure and development leads.

Here are 3 strategies to get you into better habits this year.

1) Patch groups (Manual)

Patch Groups is a way of splitting your environment into two or more groups and patching on an offset schedule.  In order to reduce downtime you will need a highly available architecture at all tiers.  Unfortunately, this is not always the case and you may need to take a few hours of downtime every few weeks.  Work with development to coordinate between release cycles and get commitment during each program increment on the patch dates.   This is the least optimal, but very common strategy.

Even with vendor specific patch management tools you are likely still stuck doing manual patching because of application dependencies. Relying on the need to bring down and bring up all systems in a specific order makes patch schedules a very labor intensive task.

2) Automated patching

Centralized automated patching is the next best way to handle a regular patch schedule.    Increasing automation and orchestration of patching should model applications and dependencies.   By doing so you will be able to be more flexible with your application teams by doing independent application patch schedules, real time patch requests, and improved compliance and variance reporting.

Automated patch management should be built into your end-to-end DevOps processes and Agile methodologies.   As before the patch calendar should be included as part of all PI planning activities.

3) Infa-as-code

Rolling out patching as part of your code release should be an ultimate goal.  The primary benefit of this is that the patching happens in parallel to the software development life cycle.   Automated patching  and orchestration discussed earlier can also enable or benefit the automated deployment process.  This allows for patching, code deployment, and testing to happen all at once.

Concerns about added time of the deployment should consider these benefits. Reducing the number of total deployments (patch and code) will decrease your total outage time. Increasing patch frequency aligned to SDLC  should reduce the variances that need to be deployed and the time it takes to do patch deployments.

Patch management tends to also be a litmus test on the overall devops strategy of the organization, as well as the release quality, efficiency, and velocity of the deployment process.   Small changes in automation can reduce effort to manage and improve the overall security hygiene of an IT environment.

Cloudland technologies has a long history in helping IT organizations improve their systems and processes through automation and technology.

Additional note:

Focus on High Availability will help with all the above strategies to decrease or eliminate downtime to the end user.  Application downtime happens when it is not architected to handle a single server outage (single point of failure). A discussion of High availability of an application goes beyond having more than one server at an application tier to include service versioning, modularization and componentization, and near-zero downtime deployments.   We will discuss in a later blog.

If you found this article helpful, feel free to share it with anyone who may be interested. Subscribe to our blog as well as follow Cloudland Technologies on LinkedIn, Facebook, Instagram, and Twitter.