Editor’s note:  PatchZone welcomes Robert Miller who will be writing a series of blog posts on PatchZone.  Robert has over 14 years of experience with network, system, telephony administration and corporate security and is currently a Security & Operations Manager for a privately held company.  Robert is also a respected security researcher.  Check out his personal blog at www.armoredpackets.com.

 

The Patch Management Process: 5 Common Sense Tips

 

When an IT professional says “We need to update the servers this weekend”, what comes to mind?

 

Many of us simply say to ourselves “Great, another weekend spent in the datacenter…”  However, few never really think about what the patching of a system or application really does; or what is the best approach to take when getting ready to deploy these updates.  Just like many things we as IT professionals do, it is not the action that counts, but rather the prep work that makes a successful deployment, or a dreaded failure.

 

So how can you put together a patch management solutions that will not only give back your weekends, be able to provide the security needed for your organization, but also prevent that dreaded failure?

 

Let’s take a look at the key areas to achieve these goals.

 

I. System Scope

II. Development / Testing Environment

III. Change Management / Change Control

IV. Patch / Update Deployment

V. System Monitoring & Vulnerability Scanning

 

One might think the process begins on the update release date.  This is not the case by any means.  The work really begins even before the very first system is built and configured.

 

I. System Scope
The system administrator, manager, director, and chief information officer need to sit down and outline the purpose of the systems.  This will include the system role as well as the baseline the system will take when first built.


What will the role be of the system?
What applications will run on each system?
What systems are mission critical, mission sensitive, business critical, general operations, and testing?


Once the system scope has been developed and documented you can move on to the next step in the process.  Until you have the scope of what the systems are going to be doing and what category that system resides in, you cannot truly have a successful patch management process.

 

II. Development / Testing Environment

When building your test environment consider 3 key characteristics – is the environment flexibility, dynamic, and accurate?  Flexibility refers to the ability of the environment to serve multiple roles.  Dynamic in the sense that the system can be changed to a different role and do so quickly. You have the flexibility of a system that can serve more than one role but if you have to spend days building it then you are not very dynamic.  Most importantly, in my opinion, is the accuracy of the system as it equates to the production system.  If it does not have the same baseline and installed applications you will not be able to test the patches properly to find issues before rolling it out into the production environment.

 

How can we achieve all three requirements?

 

Virtualize your test environment; create a clone of the physical production system.  Then prior to installing the patch take a snapshot; this way if the patch hoses something up you can simply restore from the snapshot and continue working on solutions.  Virtualization has become so vital in a testing environment; the cost verse reward is incredible.

 

III. Change Management / Change Control

Now incorporate change management.  The key is to make sure you have a process in place prior to installing the patch and even more important is the back out plan for that patch if something goes wrong.

 

IV. Patch / Update Deployment

Let’s move to actually installing the patch or application update.  During this step you need to take good notes, note anything that was required as a dependency which was not documented by the vendor.  While taking these notes you need to observe adverse reactions to the patch which may affect the production environment.

 

The rollout is the last piece of the patch deployment process.  Prior to this step you should already have a confirmed maintenance and patching schedule which will be incorporate not only what time and day of week you deploy patches but also the order of the systems based on system and security scope.


However, the process is yet to be completed!

 

V. System Monitoring & Vulnerability Scanning

Finally you need to run the systems and monitor the operation, as well as use a vulnerability scanner such as OpenVAS or Nessus to verify the systems received the patch or update successfully as well as actually fixed the issue the patch or update was supposed to resolve.


This was a brief example on the steps required in order to build a successful program.  However, understand that every organization will be different and so long as you have the methodology and support you can have a successful patch management program.