Editor's note: This is the first in a series of Tester's Challenge columns in which Network World Global Test Alliance members push the industry to remedy pressing issues that confront our readers. In turn, we will allot space in print and online for vendors to respond.

When we tested Blue Coat Systems' security gateway in the lab last year, the product manager reeled off an impressive list of security features. Great stuff, I thought; the company is serious about access control.

Then we powered up the gateway, and the available management methods - Web and telnet - made me rethink my favorable assessment. Neither of these offers secure authentication or encryption. With these methods enabled by default, it would be easy for an attacker to intercept a password and then change the device's configuration or even shut it down.

Seen in that light, none of the other features of this "security device" really mattered. How secure is a system that accepts passwords sent in the clear? Just as worrisome, how many network managers will remember to disable these defaults?

Blue Coat says it no longer supports these access methods out of the box, but it is far from the only offending company on this point. Network giant Cisco, security-minded NetScreen Technologies and numerous other equipment makers ship products with weak or nonexistent security defaults. Virtually every product I've tested in the last 18 months suffers from this problem.

We'd like to be part of the solution.

Our first challenge to all vendors mentioned in this column - and Cisco in particular as the 800-pound network gorilla - is to address the dumb security defaults they ship with their products.

There are more than a few instances of these dumb defaults, but for the purpose of our discussion, we'll point to some of the more egregious examples.

SSH: Secure shell (SSH) is supposed to offer secure access to a command-line interface. While it's better than telnet, not all SSHs are alike. Exploits of SSHv1 have been around since at least 1998.

Incredibly, SSHv1 is the only option available for many of Cisco's routers. Cisco Catalyst switches support SSHv2, which fixes Version 1's vulnerabilities, but by default these devices allow SSHv1 access as well.

By some estimates, Cisco makes at least three-quarters of all routers attached to the Internet. Given that attackers can intercept passwords, change configurations and disable devices at will, the lack of proper SSH hygiene is staggering and downright scary. When will Cisco enable SSHv2 (and only SSHv2) on every box it sells?

NetScreen also has a place in the SSH hall of shame. The company's otherwise-estimable security products support only SSHv1. To further confuse customers, NetScreen refers to SSH as "secure command shell" because of licensing issues. First-rate SSH implementations exist in the open-source world; it wouldn't hurt NetScreen to use one of these and ship products with only Version 2 support enabled out of the box.

SNMP: Like SSH, multiple versions of SNMP exist. Only the most recent, Version 3, offers strong authentication and encryption. The problem is that relatively few network devices support it.

Extreme Networks and Foundry Networks have added SNMPv3 support to their line of Ethernet switches, but neither vendor supports this secure management method by default. To both vendors' credit, the earlier, unsecure versions of SNMP aren't enabled by default either - but once they are, it will take an attacker approximately 1 nanosec to guess default community strings and password.