Patch management is just one of the necessary evils that cause us pain month after month with the onslaught of patches that come from various software vendors. If you are new to the patch management game, or have just taken on the duties of the patch administrator in your company or organization, here is a simple framework that can be used to begin or augment any company's patch management process.
Note: The following documents by the US National Institute of Standards and Technology (NIST) SP 800-30, Risk Technology Guide for Information Systems and NIST SP 800-40v2, Creating a Patch and Vulnerability Management Program provide checklists and additional documentation on establishing your own risk management and patch management frameworks.
Let's first take a look at the framework:
- Step 1: Review your internal security policy
- Step 2: Take an inventory of your assets
- Step 3: Rank-prioritize your assets
- Step 4: Document existing controls
- Step 5: Perform a risk assessment of existing vulnerabilities that affect assets under your control
- Step 6: Patch systems
Now that we have identified a simple framework around how best to structure our patch management duties, let's take a look at each of the steps individually and illustrate what we need to be looking for in each.
The first step is to review your internal security policy. This document or set of documents is usually a very high-level view of management's expectations as it pertains to the security of all assets within the organization. What you are looking for, if it's available, are the requirements in a process or procedure for the risk-management of informational assets and any timelines for patching critical systems. In my time as a patch administrator, I have rarely seen this step well-documented, but look at this as your opportunity to shine. Apply what you have learned here and provide a process and procedure around how you are going to patch and manage the risk to your systems according to the guidelines and provisions set forth in your internal security policy.
The second step is to clearly detail what assets you are responsible for, take the time to create clear documentation of the hardware, software, services and communication protocols your assets communicate over and identify which systems they are connected to both internally and externally. Clear and detailed documentation of your assets gives you a complete picture of which version(s) of firmware, software, services or communication protocols currently are in use making the known vulnerabilities easily identifiable. Anything which might be exploited by a threat (worm, exploit code, Trojan, etc.) would raise the risk-level on the assets owned or managed. There are various websites out there that have documentation on past and present vulnerabilities in various software products. I would highly advise you to sign up for their email lists, review the alerts, and take a look at your systems to see if you have vulnerabilities that you weren't previously aware of.