Network Computingwww.networkcomputing.com

When we first looked at vulnerability-assessment packages (see "IP-Based Security Auditing Tools" at www.networkcomputing.com/913/913r1.html), we had concerns about their lack of detailed reporting mechanisms, poor interface design and mediocre performance; many of these issues have been addressed. However, major problems concerning the frequency of available product updates linger: These products need more timely updates.

Vulnerability-assessment packages deliver a wide range of benefits, but their strongest value lies in their ability to identify a vast range of security holes and misconfigurations. Much like virus scanners, the products use internal databases of known flaws to determine whether a system is vulnerable to a specific type of attack. Of course, this could be done by hand, but an administrator would first have to possess a checklist of several hundred known security problems (and fixes), and audit each system with those particular holes in mind. It would be a daunting task with just several dozen machines; it's impossible with several thousand.

Another problem with relying solely on manual audits is that no single all-encompassing source for known security holes exists. Although some administrators may have the time to sort though the piles of e-mail that security mailing lists generate, most administrators do not. Maintenance of the internal store of security holes found in any vulnerability-assessment package is the responsibility of the vendor--not the administrator. The theory is that by keeping current versions of scanning tools on hand, administrators will be able to spend less time researching security holes and more time fixing other problems. The reality is that this is not a simple task.

Before fully examining the issue, let's look at the cause. The life cycle of a security bug or exploitable hole usually follows a routine path. First, an individual or group discovers a flaw that lets an attacker do something that he or she shouldn't be able to do. The discoverer then does one of three things. One, he or she may report the bug to the vendor in the hope that the company will promptly issue a patch or hot fix; this is the preferred path because the exploit, the advisory and the fix can be released in one fell swoop. Two, the discoverer may go directly to a public security list, such as Bugtraq. This notifies the community of a programmer's mistake and may inspire a quick fix. This may be the best and only option if a vendor ignores a known security issue. Three, the discoverer will keep the information on the bug quiet, telling no one or only a small group of colleagues. Depending on the individual's motives, this can be dangerous because it creates a security trump card for any attacker who knows about the hole.

Revisiting the concept of automated scanning, once the security vendors are made aware of the new hole, checks are coded, integrated and pushed out into the next product revision. Placing ourselves in the role of the attacker, if we want to break into a system we have a better chance of success if we use a newer attack method. If administrators don't keep current with the patch levels, they are likely to be victimized. If they aren't even aware of the hole, they are an additional step behind.

Although timing will always be an issue regarding security, the current revision time lines compound the problem. Vulnerability-assessment vendors that release updates every two to three months force administrators to keep current on vulnerability announcements or risk remaining vulnerable to attacks that are known by the cracking community but unknown to them.

When examining assessment tools, first consider the scope of the tool's use. For example, products such as Axent Technologies' NetRecon not only scan over IP, but also IPX and NetBEUI for certain checks. ISS's scanning suite can dig through database permissions and perform comprehensive analysis of NT internals. Network Associates' Cybercop Scanner has some custom packet-generation ability not found in any other scanning products. You should be clear about for what you will be using the package prior to making any purchasing decisions.

Next, factor in portability. Some products limit you solely based on the number of hosts scanned; others restrict you to fixed IP ranges. Anyone using ISS's products knows what a pain the key cutting routines are. Make sure you know what type of licensing methods the product employs before you commit to it.

Finally, look at total cost. Some scanning products, such as Nessus, are free, but the cost of most commercial offerings runs into thousands of dollars. In a bold move, Cisco recently dropped the price of its vulnerability- assessment package, NetSonar, to $499 for a Class C network--it is now priced at thousands of dollars less than competing commercial products. In comparison, Network Associates has a bizarre per-node charging system determined not on a per-machine-you-want-to-scan basis, but rather by how many nodes your enterprise has.

For anyone performing widespread system auditing, a vulnerability assessment tool is invaluable. But if you choose to rely on it as your primary means of defense, you're bound to get burned.

--Greg Shipley