Internet Explorer 11 is not supported

For optimal browsing, we recommend Chrome, Firefox or Safari browsers.

Don't Bug Me

Protecting network systems against virus attacks takes good management--and a little bit of luck.

Steve Steinbrecher teaches an MBA class on Internet management in his off hours. When the Sapphire worm came slamming through servers around the world in January, the Contra Costa County CIO got an early morning phone call from one of his students who works for a large company that had just gotten hit by the virus, warning him about it. Steinbrecher quickly called his wide area network gurus just as warnings about the virus were beginning to pop up on the Internet. Network managers isolated all county servers from the rest of the world and no problems cropped up on the county network. "I considered us to be pretty damn lucky," he says.

Lucky? Shouldn't protection of network systems against sinister virus attacks rely on more than luck? Absolutely, Steinbrecher agrees: luck and good management. He and other CIOs suggest important management steps to take. They include teaching employees not to be sucked in by alluring e-mail messages, assigning technicians to keep up to date on software upgrades that protect against viruses and having a back-up plan if systems do get hit, as they did in Bellevue, Washington, recently.

When a government gets snagged by a virus, the first reaction often is to blame employees for not having virus-protection software in place. They may have been negligent, but they also may have been caught in a bind. Often, loading virus-protection software onto a feature-rich, complex network containing many different kinds of software can disrupt the network, perhaps doing more damage than if the actual virus hit it. "You have to balance risk with known consequences," says Kirk Bailey, chief information security officer in Seattle.

Contra Costa County manages the application problem by testing anti- virus patches before allowing them to run on county servers. That can sometimes take months, especially since the number of new patches can average five or six per day. The lag between testing, approving and loading those fixes can stretch out. The result is that government systems do get infected on occasion. "This technology is not easily managed," Bailey says. "You're bound to miss a patch or decide not to apply one for good reasons and then you could get nipped by something." Also, technicians don't walk up and apply patches at random. It's usually part of a scheduled process established under a government's polices or practices.

Whether or not a patch is applied, governments still have to keep up with what's available. Michael Armstrong, Des Moines' CIO, has assigned one person the job of checking every day at 7 a.m. for updates from the city's virus-prevention vendor. It's a discipline that has to be instilled in your staff, Armstrong says. "You can't leave it to chance or check it once a week or so." Even that does not guarantee protection. There's always a time delay between when a virus shows up and when a remedy becomes available. In one instance, the city's system got hit because a patch wasn't ready yet.

Armstrong also is an advocate of making sure that users know about viruses immediately so they don't open suspicious e-mail and launch a virus. Personnel management on this issue is tricky, since intriguing e-mails draw employees in. Armstrong laments that no matter how quickly people are told about suspicious ones, "there's always someone who's already opened the sucker." That doesn't diminish the importance of making users aware. Lately, the city has been getting a lot of hoax messages telling people to delete critical files. It's Armstrong's job to keep county workers from following those directions.

Should disaster strike, think "back-up." When the recent worm ate into Bellevue's computer-assisted dispatch program, the emergency communications system dispatchers quickly reverted to back-up processes. Could other government systems rise to their pre-electronic tasks if need be? It's worth knowing before a computer attack takes place.

One more step that Steinbrecher requires of his staff is that they be meticulous about documentation. If a security problem arises that is not documented, some staff member is going to get a few days off without pay. On the other hand, he trusts his people and gives them some leeway in their decisions about software fixes. "I tell them, 'Please be as vigilant as you can. Apply these things as quickly as you can.'" After that, he crosses his fingers.

Special Projects