Deployment and Metrics

["Michael Penaska" <[EMAIL PROTECTED]>]

List,

I've included a guide to Security Metrics Reporting released by NIST
(Special Publication 800-55) last July. Unfortunately, this guide does not
place specific emphasis on patch management, but I mention it for a specific
reason. During a recent conversation with a colleague, we came to an
understanding that within a company (particularly a large firm) patch
management consists of two processes: firstly the deployment of the patches
via whatever vehicle the firm deems appropriate (which we all seem to like
to debate!) and secondly the verification that these patches are in place,
have been successfully installed, etc. My area of concentration is not the
distribution process, but the verification process which leads to
all-important Reporting. Let's face it, in the industry, reporting can cost
jobs should management feel progress isn't made at an appropriate rate.
Naturally, many of the large scale PM solutions feature detailed, packaged
reporting schemas. Some even allow a nice degree of customization. However,
two contentions arise. It's common knowledge that not many of the large
solutions cover non-MS operating systems. Also, those that do, often have
rather unsatisfactory reporting features. For the time being, some firms
have turned to internal solutions (net-crawling scripts [in the spirit of
the original HFNetChk.exe], etc) to measure deployment effectiveness.
Particularly in large, complex spaces. I cite this report only as a means to
guide administrators' metrics reporting methodology. A simple case would be
keeping the process logic in check. For instance, if a custome tool tells
you in its report that it has done its job, that doesn't really help you
much, because it leaves the "follow through" up in the air. However, if it
can cite an OS generated return from a system command call, that can be
logged and trusted without worry of false positives. Much of this may seem
very elementary, but it has been my experience with reporting admins that
fundamental ideas about valid reporting data seem lacking. Otherwise, all
those pretty charts are just that: only pretty colors and no meaning. In
short, I suppose I'm only crying out for the same as every other patch
management consumer: better reporting schemes. The most recent Network
Computing article projects that PM is simply running its course of
development and may even be consumed altogether by Desktop/Enterprise
Management in a few years. For those who can't wait, I think this report
provides a good basis for reporting methodology as applied to any security
metric, including patching.

http://csrc.nist.gov/publications/nistpubs/800-55/sp800-55.pdf

Michael



---
To unsubscribe send a blank email to [EMAIL PROTECTED]