Mailbag: Patch management

In my recent article on the Slammer worm bringing attention to patch management issues, I talked about the importance of network managers’ diligence and discipline in applying software patches. In response to that article, I heard from several readers who voiced another perspective on software patches – they all agreed that managing patches is an important thing to do, but felt that the software vendors also have a responsibility. Here’s what a few readers had to say.

One reader says:

“While I realize that patches are a necessary part of applications, it seems there are an exorbitant amount of patches coming out of Microsoft, including ones that actually cause problems. Microsoft has implied that Slammer was not its fault, since [Microsoft] had issued a patch six months prior. However, that patch caused issues which made companies (including Microsoft) not want to install it. I feel that as a writer, you should not be stating that patch management needs to be beefed up. Rather, if vendors (Microsoft in particular) minimized the patches then it would be easier to install them… Microsoft needs to realize that either the software gets done right the first time, or managers need to start looking at alternatives that do not have ‘weekly’ patches.”

He goes on to say, “Every vendor (at least reputable ones) has patches – it’s practically a given with software. However, Microsoft has an excess of patches. I am on their developer list so I get e-mailed when they produce patches for any product. I get e-mailed at least once a week – usually more – including patches to fix problems from other patches. What company, besides Microsoft, ships products that are expected to have patches? In fact, most managers will wait till SP1 before using a Microsoft product.”

Another reader had a positive experience with other software:

“You make it sound like all software suffers from this problem, which is not true. If you said ‘popular software’ then that would be correct. For example: I can count on one hand the number of security-related patches I’ve had to apply to the OpenVMS systems I’ve managed over the last 15 years. It’s simply not an issue – perhaps in part the lower profile of such software makes it a less attractive target. That’s not all of it however – a lot has to do with the quality of software engineering. Nevertheless, there is an advantage in using software/platforms that are not the most popular.”

On another note, here’s an example of how Aprisma was able to avoid the financial and technical impacts of the Slammer worm using its Spectrum software internally. This came by way of Aprisma’s marketing department:

“Spectrum’s WAN bandwidth monitoring provided information to the IT group that the inbound Internet traffic had exceeded the contracted committed information rate (CIR) and was abnormally high, as compared to baseline general usage. It was determined that there was specific traffic consuming the inbound Internet connection. Spectrum was used to first identify the affected socket/port and then a phone call was placed to Aprisma’s ISP to lock it down. After locking down the socket/port, the traffic returned to normal levels. In addition, Aprisma IT was able to notify its ISP before they knew a problem existed – also allowing them to lock down the socket/port for other affected customers.”

Aprisma avoided the “soft-dollar costs from lost productivity across all aspects of the business,” as well as the “hard-dollar costs associated with exceeding the Internet bandwidth CIR threshold for an extended period of time… the service provider would have billed Aprisma several thousand dollars for the overage.”

Many thanks to our readers for sending in their viewpoints on the Slammer worm.