Implementing and Managing Patch and Configuration Management: Defining Policies
So far we have focused on all the preparatory work and technology deployment that needs to happen before you can finally flip the switch and start using an endpoint security management tool in production. With the pieces in place it is now time to configure and deploy policies to prepare for the inevitable patch cycles, and to start monitoring configurations on your key devices. The first major choice is between the Quick Wins and Full Deployment processes – Quick Wins is focused on information gathering and refining priorities & policies – proving the tool’s value and making sure your results from initial testing weren’t misleading. Full Deployment is all about full coverage for all endpoint devices and users. We generally recommend you start with Quick Wins, which produces much more information and treads a bit more lightly, before jumping into Full Deployment. Who knows – you might even realign your priorities. But even after a few Quick Wins, a structured and (somewhat) patient path to Full Deployment makes the most sense. Iterative Deployment Before we get deep into staging your deployment, keep in mind that we break things out with extreme granularity, to fit the full range of organizations. Many of you won’t need this much depth, due to organizational size or the nature of your policies and priorities. Don’t get hung up on our multi-step process – many of you won’t need to move this cautiously, and can run through multiple steps quickly. The key to success is to think incrementally – too often we hear about organizations which can pump out a bunch of agents quickly, so they think they should. Endpoints can be finicky devices, and you should be sure to provide adequate time for testing and burn-in before you go all-in on deployment. So it’s prudent to pick a single device type or group of users, create the appropriate policy, slowly roll out, and tune iteratively until you attain full coverage. We are not opposed to deploying quickly, but we have a keen appreciation for the challenges of fast deployment – especially in managing expectations. Better to under-promise and over-deliver than vice-versa, right? So here is a reasonable deployment plan: Define the policy: This involves setting policies based on the type of device and what you are doing on it – patch or configuration management. We will dig into the specific policy decisions you need to make later in this post. Again, we suggest you start with a single device type – possibly even for a specific group of users – and expand incrementally once the first deployment is complete. This helps reduce management overhead and enables you to tune the policy. In most cases your vendor will provide prebuilt policies and categories to jumpstart your own policy development. It’s entirely appropriate to start with one of those and evaluate its results. Deploy to a subset: The next step is to deploy the policy to a limited subset (either device types, groups of users, or both) of your overall coverage goal. This limits the number of deployment failures, and gives you time to adjust and tune the policy. The key is to start small so you don’t get overloaded during the tuning process. It is much easier to grow a small deployment than to deal with overwhelming fallout from a poorly tuned policy. Analyze and tune: During analysis and tuning you iteratively observe results and adjust the policy. If you see too many deployment/remediation failures or false positives you adjust the policy. Expand scope: Once the policy is tuned you can start thinking about expanding the deployment scope and size. You can add additional devices and groups of users, expand the number of applications being patched, etc. Full deployments should rarely happen as a big bang, so grow it slowly and surely to ensure you don’t risk the perception of deployment success by going too far too fast. Smaller organizations can often move quickly to full deployment, but we strongly suggest starting small – even if it’s only for a day. When setting up the policies it makes sense to revisit the processes for both patch and configuration management – as they govern what the tool does, what you and your staff do, and what outcomes you can expect. So let’s touch on each process and the associated policy decisions you need to make. Patch Management Policies In a perfect world, the patch management engine would just run and you could get back to World of Warcraft. Alas, the world isn’t perfect and patch management isn’t nearly as automated as we would all prefer. You can automate some aspects of the process (including monitoring for new patches), but ultimately you need to define which patches get applied in what order and build the installation packages. The good news is that once this is done the tools generally do a good job of automating installation, confirmation, and tracking. But there is still significant work to do up front. Put another way, patch management policies are unique for every patch cycle. Of course you can define consistent aspects of the process (such as maintenance windows and user notifications) for every cycle, but every cycle you need to decide what gets patched and what doesn’t. 1. Discovery and Target Definition Depending on whether you are rolling out a Quick Wins limited deployment, extending an existing deployment, or going all-in with a big bang full deployment, the first step is to load up the system with the devices to be managed. Besides loading up the assets you need to decide what to do when a new device is found to be out of compliance with policy. Do you force a patch deployment right away? You also need to define the frequency of revisiting the asset list (daily, weekly, monthly, etc.), because new devices need some endpoint security management love as well. 2. Obtain Patches The next step in patch management is actually finding the patches applicable to your environment. Here
