Now, I'm not a doctor, and I don't play one on television. And I'm not a chief security officer, but I will play one--however superficially--for the purposes of this column.

My career shift was triggered by a news item that appeared late last week in our InformationWeek Daily E-mail newsletter (informationweek.com/867/solaris.htm) about a security flaw in Solaris 8: "Security vendor Internet Security Systems Inc. is warning users of Sun Microsystems Solaris 8 and earlier versions that a serious vulnerability gives hackers 'super user' privileges. According to an alert published by ISS, the vulnerability in the 'login' program in Solaris enables attackers to run arbitrary commands on a target system."

The story went on to add that while Sun declined to comment, Internet Security Systems' warning stated that "Sun is aware of the vulnerability and is testing a fix. Patches may be available soon." And I wondered how soon those patches could be grabbed and installed by customers (Sun wasn't responding to inquiries about this from George Hulme, our senior editor who covers security and the author of the story)--are we talking days? Weeks? And how many Solaris 8 customers saw the independent advisory? Was Sun itself informing its Solaris 8 customers?

In this age of growing awareness of personal responsibility, what about the customer side: Once they know about the flaw and find out where and when to get the patches, how many IT departments will actually locate, download, install, monitor, and test the patches? All? Most? Half? And for those that don't, why not? Too much trouble? Not much risk? Not my job?

So I took a look back at another story written by Hulme on security and hackers that discussed a security flaw based not in the code but rather in that most complex of all programs: human behavior.

In a story published in InformationWeek in August ("Full Disclosure"), Hulme writes, "Clearly, some of the blame falls on IT managers for not installing publicly available patches. Hackers have been known to exploit vulnerabilities weeks, months, sometimes years after flaws have been made public and patches made available. Early last year, a hacker calling himself Curador stole more than 25,000 credit-card numbers from small E-commerce Web sites by exploiting a well-known Microsoft security flaw, even though the vendor had published a patch."

Hulme went on to quote a network administrator with a major medical company who said, "Security often takes a backseat to other projects that management deems more important, and the resources aren't always made available to put patches into place immediately--or even within weeks."

Back in the summer, Code Red infected more than 350,000 networks, crippled Web sites, and even managed to slow down overall Internet traffic. History, human nature, and a combination of technological progress and technical limitations offer us more than ample evidence to believe Code Red won't be the last widescale virus, nor will it be the most destructive. All of those points would seem to require a dramatic reordering of priorities in companies where, as noted in the quote above, security is mostly an afterthought.

For you CIOs and chief security officers out there: Is patch-installation a priority in your company? Is it talked about and hyped, or is it truly valued? Is it part of a compensation package? Do you keep a list of flaws, availability of patches, and installation of patches? Do you want to face the CEO when she asks, "You mean we knew about this virus but didn't inoculate ourselves?"

The serenity prayer asks for the serenity to accept the things that cannot be changed, the courage to change the things that can be, and the wisdom to know the difference. The rising tide of security's value in today's business-technology world mandates that we all take the initiative.

BOB EVANS
Editor-in-Chief
[email protected]

To discuss this column with other readers, please visit Bob Evans's forum on the Listening Post.

To find out more about Bob Evans, please visit his page on the Listening Post.