While we don’t plan on posting every Project Quant update here on the main blog, we will be cross-posting some of the more significant project updates, as well as other content we relevant to our broader readership. (For these posts we will turn off comments to consolidate them all in the Project Quant area.)

So here is our first pass at defining a patch management process for the project:

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:

  1. Monitor for Release/Advisory: Anything associated with tracking patch releases, since all vendors follow different processes.
  2. Acquire: Get the patch.
  3. 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?
  4. 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.
  5. 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.
  6. Create Deployment Package: Prepare the patch for deployment.
  7. Deploy.
  8. Confirm Deployment: Verify that patches were properly deployed. This might include use of configuration management or vulnerability assessment tools.
  9. Clean up: Clean up any bad deployments, remnants of the patch application procedure, or other associated cruft/detritus.
  10. 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…

To comment on this post, please see the original over in the Project Quant area.