Like the cobbler's children who have no shoes, system administrators often have no awareness of security requirements that apply to them. Well, more correctly, they often ignore such requirements. In fact, I can't tell you how many times I've seen security audits detect some outlawed application on the network, and then traced it back to an administrator's machine. As recently as two weeks ago, I was at a large company, where the head of their standards setting "Security Counsel" was running a Kazaa server on his workstation.
One of the reasons this is true is that network administrators spend half their time building and tweaking and testing equipment, whether it's firewalls, PCs or routers and switches. And the other half of their time, they spend maintaining their networks with all sorts of specialized tools. These activities are very "high risk" and there are a lot of steps administrators should take to minimize their risk.
First, build a lab or "build" a network, separate from your production network, in which you can build and test equipment, without worrying about what level of patches or service packs you have. Usually, you'll want to 'dual-home' a file server so that you can download necessary files, or better yet, burn the files you need to CDs. Using a Windows server to do "Port Address Translation" is also an option, as it can help prevent access into this private lab and only takes a few clicks to set up. This will help alleviate the problem of unauthorized
Next, get an accurate inventory of all your network management stations. Lots of administrators re-deploy old PCs to run network management tools like MRTG (multi-router traffic grapher) or to act as route servers or boxes to collect syslogs, etc. Unfortunately, these systems are highly susceptible to worms, as they are often overlooked when new patches are released; having a valid, up-to-date list will help with this problem.
Distributed or dedicated protocol analyzers, running on Windows OS are also vulnerable. Keep them updated, or shut them off when they're not in use. Finally, don't allow these boxes to belong to the same Windows Domain as your production servers.
Thomas Alexander Lancaster IV is a consultant and author with over ten years experience in the networking industry, focused on Internet infrastructure.
This was first published in May 2003