4 Patch Management Practices to Keep Your Network Secure
Patching is vital to securing systems from known vulnerabilities, but it’s also a risk that can bring down those systems if you deploy a bad patch. In order to maintain the proper risk balance you should focus on patches that close vulnerabilities.
Even once you establish your risk balance, you are continually under the threat of a CNN story about the latest vulnerability and the unexpected patch that must be deployed to close it. Building repeatable processes that solve this security/availability balance keeps your systems secure and keeps you ahead of emerging threats.
Here are four keys to expert patch management:
1) Solve for Third Party Applications
Hacking has evolved into an organized business looking for the fastest way to exploit as many systems as possible. Secunia’s 2014 Vulnerability Review calls out that 76% of vulnerabilities are related to third party applications, outnumbering Microsoft applications such as Office (16%) and Windows (8%).
2) Manage the 5%
The 95/5 rule is the theory that the majority of patches approved for deployment will apply to most of the systems you manage. The trick is identifying and managing the 5% of exceptions. Although it is tempting to handle patch approval on individual computers, building groups or policies to handle exceptions is the more scalable solution.
Your next step is to identify systems with unique patching requirements and apply exceptions to those systems. If you know a line of business application will fail if an MS-SQL service pack is installed, being able to identify a new system with the same line of business application and automatically deny that service pack avoids a potential service outage.
3) Save Time and Remove Clutter
Most organizations have default approval policies for common patch categories such as critical updates, security updates, language packs and drivers. Being able to automatically approve or deny patches based on category will reduce the number of patches you need to review each Patch Tuesday. With third party applications this becomes more critical as the release cycles for third party applications can reoccur randomly throughout the month.
4) Stage Patch Deployment
Blindly pushing patches to all systems without validation can be a recipe for mass disaster. Microsoft has had several patches in the past year that have had an adverse impact, forcing those that did not test to remove them or deal with the impact.
Patch staging is a process where you apply patch approval to a series of separate groups of systems. Patches are deployed to each group prior to moving on to the next group to validate their quality before releasing them to the majority of your systems. For example:
- Stage 1: A smaller number of trusted internal systems or lab systems
- Stage 2: A sample of production systems testing compatibility with line of business applications, while still limiting exposure
- Stage 3: Release to the rest of your managed systems
Once you are ready to install, avoid patching critical systems all at the same time. You can minimize outages by patching higher risk systems prior to internal systems, patching based on server role to solve for dependencies between servers, or by staggering deployment to different locations within the company. While staggering the deployment of patches to avoid outages, you must also balance the risk of systems that remain unpatched and vulnerable.
These patching best practices are meant for you to adopt and mold to fit your business. The policies you implement should solve for the requirements of your business and the systems you manage. Once you have defined your patching policies, implementing them on regular basis each month is the key to success.
—
This article was provided by our partner Labtech who provide third party patch management tools to service providers.
