Creative Patch Testing Workarounds
Regarding "Patch Testing Past Its Time?" (January 2007), I am a systems analyst and the network administrator for a small company (about 100 users). I don't have a separate test environment for thorough testing of patches released by Microsoft. What I do have is a patch manager application by Numara Software, which has an agreement with Shavlik Technologies, so my patches actually come from the Shavlik database and Web site.

My second layer of defense against problem patches is staged scheduling. I have a schedule set up where a small group of servers and XP workstations is patched and rebooted in the middle of the night starting on Patch Tuesday. Each night through the next weekend, a small group of servers is patched and rebooted. The only problems I've run into so far is the occasional "end program" error Windows displays while trying to shut down, or the occasional hanging of a server during the shutdown process.

The above scenario is a pretty decent workaround for not having the same resources as larger, enterprise-level companies, and allows me to push more than 95 percent of the updates that would normally come from Microsoft Windows Update.

The next stage will be to incorporate a Windows Update Services server, and set the options that will allow me to approve updates before they are made available to the workstations. That will be my final line of defense. By manually approving my WUS patches, I hope to prevent users from installing Windows patches the day Microsoft releases them.

It's not exactly thorough testing, but at least IT runs all patches in a production environment for about a day before users get them. Smaller companies need to think creatively about patch testing. This workaround took quite a bit of experimentation and a few calls to tech support to nail down a scenario that would work.

But I would say it helped automate 85 percent or more of my patching needs.

Doug Porter
Apex Microtechnology

The Futility of Secrets
I agree with Marcus Ranum (Face-Off, January 2007) that we must stop living in denial about the futility of using easy-to-compromise secrets to authenticate people and transactions. However, the fix he proposes is futile too: One-time passwords of this kind are susceptible to well-known attacks. There are much stronger authentication technologies available.

Yes, Bruce Schneier has it right in pointing out that the problem is mainly economic, but he is wrong in saying we should give up on fixing the authentication of people. The payment card industry has introduced smart cards in Europe where, for example, a person paying at a restaurant is presented with a portable wireless payment terminal and must insert the card and then enter a PIN before the transaction is approved. This eliminates the possibility for the waiter to go in the back room and record the card details so that he can place a fraudulent transaction later. There is no other way to explain the resistance of the payment card industry to introducing this technology here than to paraphrase Bill Clinton's election slogan: "It is the economy, stupid."

Just try to imagine what a horrible reality we could be living in if the auto industry in this country had the luxury of using the approaches of the payment card industry. The number of people in the United States involved in car accidents compared to the total number of people driving is small; it is also a fact that the society is not at risk as a whole, even if all traffic accidents were fatal; so, what if the auto industry skipped safety technologies such as seat belts, airbags, anti-lock brakes, etc.?

Indeed, let's work on fixing the economic problems first and then introduce comprehensive privacy laws.

Apostol Vassilev
President, CEO, NetIDSys

Correction: A story in the February issue ("Going Global") incorrectly described Verispan as participating in the U.S. Safe Harbor program.

Send your e-mails to feedback@infosecuritymag.com.