Patching: The Risk Evaluation of Patching

One of the things I briefly touched on in my last post was that we used a risk evaluation process and tools for building intelligence around new patches. To expand on that, and give you a better idea of what the intelligence component looks like, I thought I’d take a second pass at the topic.

So whenever we have new patches released (I’ll focus on Microsoft patches for moment) the first thing we do is go in and review all patches released for the current month. This is the component that every IT professional who’s connected to patching should be doing anyway… the initial review consists of using the current release and evaluating everything - from the executive summaries and the vulnerability details, to the mitigating factors, workarounds, and on down through the FAQs. Once this initial review is completed the person doing the review should have a good handle on the scope of the patches – similar to the knowledge level that Susan talked about in her approach to Risk Evaluation. Next, it’s the person doing the initial review’s responsibility to build intelligence using our internal Patch KB.

So what does building intelligence look like?

It’s exactly what it sounds like. The person(s) responsible for the initial review takes what was learned during that initial evaluation and captures the knowledge in our internal database. Essentially they fill a form inside of an application that includes all of the relevant patch codes (vendor patch IDs, CVE codes, VU numbers), summary information, mitigation intelligence, projected risks, applicable operating systems, and so on.

Aren’t you just re-hashing what the vendor has already released?

It’s more than that. We’re taking the vendor’s patch information and then having one of the more senior sysadmins evaluate the patches, add intelligence where they think it’s appropriate, link additional information, and record the OS and application compatibility information. Once it’s in the database, patches can be cross-referenced easily and risk and status information communicated to technicians and relevant stakeholders graphically. So when a technician needs to know, “hey, is MS06-053 something I need installed on these SBS 2003 servers tonight?” They can go to the Patch KB and find out that, 1) No, it’s not an urgent update because the SBS2003 servers that we support don’t have the indexing service enabled, but that 2) Your Windows 2000 and SBS 2000 servers are at an increased risk if they are running under the default configuration with IIS installed and the Indexing service turned on.

Beyond that, each technician has an individual profile where they can virtually build-out the servers that they support – including the application stacks. So instead of just using the Patch KB for searching, they can receive a summary report for the servers that they support which include risk status information, patch summary information and recommendations all rolled into one report.

But what if a patch breaks something?

That’s another place where having the Patch KB tool really adds-value. So when we do have a problem with a patch, and someone needs to contact PSS for resolution, each technician can then add to the known-issues section. Depending on the severity of the issue, it will adjust the patch-risk level, as well as serve as a “forum” for collaboration. Further, if it breaks a particular application in the application stack (and the application has been added to our supported application framework), the cross-reference on the application will add to the risk-level based on the individual user profile.

Does it fit into your work-flow?

Yes it does… Besides myself, I haven’t met too many people with a passion for patch-management – so having a tool that enables technicians to make informed decisions, and share information with the rest of the organization is great. Not only that, but it prevents “islands of intelligence” from developing that are disconnected from the rest of the organization. Most importantly, it subdivides labor and let's people who are capable and interested in doing patch-review focus on that, while everyone else can focus on generating revenue.

What about emerging issues?

We frequently review information as it becomes available from any number of sources – the vendor sites, reputable blogs, US-CERT, SANS ISC, etc. and add this information to the KB.