Project Quant: Patch Management Cycle
Although we posted some of our initial thoughts, and have been getting some great feedback from everyone, Jeff and I realized that we haven’t even defined a standard patch management cycle yet to start from. DS, Dutch, and a few others have started posting some metrics/variables, but we didn’t have a process to fit them into.
I’ve been researching other patch management cycles, and here’s my first stab at one for the project. You’ll notice it’s a little more granular than most of the other ones out there – I think we need to break out phases in more detail to both match the different processes used by different organizations, and to give us cleaner buckets for our metrics.
Here’s a quick outline of the steps:
- Monitor for Release/Advisory: Anything associated with tracking patch releases, since all vendors follow different processes.
- Acquire: Get the patch.
- Evaluate: Initial evaluation of the patch. What’s it for? Is it security-sensitive? Do we use that software? Is the issue relevant in our environment? Are there workarounds or dependencies?
- Prioritize/Schedule: Prioritize based on the nature of the patch itself, and your infrastructure/assets. Then build out a deployment schedule, based on your prioritization.
- Test and Certify/Accredit: Perform any required testing, and certify the patch for release. This could include any C&A requirements for you government types, compliance requirements, or internal policy requirements.
- Create Deployment Package: Prepare the patch for deployment.
- Confirm Deployment: Verify that patches were properly deployed. This might include use of configuration management or vulnerability assessment tools.
- Clean up: Clean up any bad deployments, remnants of the patch application procedure, or other associated cruft/detritus.
- Document and Update Configuration Standards: Document the patch deployment, which may be required for regulatory compliance, and update any associated configuration standards/guidelines/requirements.
This is a quick and dirty pass and meant to capture the macro-level steps in the process. I know not all organizations follow, or need to follow, a process like this, but it will help us organize our metrics.
Let me know what you think – I’m sure I’m missing something…