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.

Deploy.

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.

Comments:

By -ds- on 04/30 at 10:32 PM

Suggest re-ordering:

-Monitor
-Evaluate
-Acquire: You won’t get a patch if it isn’t relevant as determined by the “Evaluate” process
-Create Deployment Package: Likely done as part of, or before, “Test/Certify”, since the deployment package would need testing just as the actual patch would.
-Test/Certify: Is it disruptive or not? This will have a lot of impact on schedule.
-Schedule
-Deploy
-Clean up: all installs should be done before validating, else validation would not be as efficient as possible.
-Confirm Deployment

Thinking about it, Deploy->Clean up->Confirm is really a sub-cycle in the process, since unless you have a 100% first deployment, you will find missed hosts in the confirm phase which need to be re-run through deploy, some of which may require assistance, and so on.

By Jeana on 05/07 at 05:03 AM

test

By Robert Rhoden on 05/08 at 04:56 PM

I’ve done matrices in the past. Seems like there should be a time variable in there somewhere.

By Oddbj on 05/09 at 10:56 PM

This may be implicitly covered by phase 8, but I think there should be an explicit gap analysis phase which aims to identify nodes or software instances in the infrastructure, but outside the current scope of the patching process. After all, we can’t patch what we don’t know about. In addition, there should perhaps be a phase 0, establishing the scope of the patching process (ie. are we trying to patch ‘database servers’, ‘Oracle products’ or ‘Oracle RDBMS instances’)—unless this is defined, it will be hard to look for relevant patches. Phase four might be renamed ‘Triage’?