NetSec Letter #26, 12 April 2003
Beyond the VA Scan

Fred Avolio, Avolio Consulting, Inc., http://www.avolio.com

Vulnerability assessment tools are important to our network and computer defensive arsenal. They are especially useful for verification testing. But, we have to do more than hand over $60,000 to some outside firm in exchange for a 100 page, boiler-plated document. Vulnerability assessment reports are most useful after we classify critical systems, and then comprehend what the report is telling us, critique its applicability to our organization, and customize what we test in future assessments.

Not useful

So, you — or someone to whom you’ve paid a lot of money — have run some tool or tools against your network, firewall, and key servers, or perhaps against your one and only web-site. You have a report that has a graph showing you that the severity of 20% of the vulnerabilities are "high," 30% are "medium," and 50% are "low."

If you are lucky, or properly negotiated the contract, you also have a written analysis by an expert, with recommendations. The report will contain false alarms — things that could be problems but are not. If you scanned your whole network for vulnerabilities, you have alerts relating to each of the systems, with no consideration of the importance of the system. Where to begin?

Make useful

To make reports like this useful, you need to start before the scan. I want to give you 4 recommendations to enhance the usefulness of vulnerability reports.

1. Categorize and classify your systems. You can make up your own categories and classifications. Some examples of categories are "firewall," "Internet-connected router," "Internet-connected web server," "e-mail server," and "user desktop." Classifications might include "mission critical (must never be off-line)," "mission important (should not be unavailable for more than 1 hour)," "user important (needed for an individual’s work)," and so on. The reason should be obvious. The most important systems get more attention than the less important systems. In the event of a security incident, these are the systems you check out first. If systems need repair, they get attention first. It is also useful to categorize by operating system.
2. Test key and representative systems. With this list, test important and representative systems, but not necessarily all systems. You must make sure it really is representative. (For example, if you have both NT and Solaris web servers, you’d better test both types.)
3. Create a "things to check/fix" list. From the representative reports for the various categories and classes of systems, see which vulnerabilities reported are true vulnerabilities. For example, a recent scan of an e-mail server came up with this "problem": The remote SMTP server did not complain when issued the command: ‘MAIL FROM: |testing’. This probably means that it is possible to send mail that will be bounced to a program, which is a serious threat, since this allows anyone to execute arbitrary commands on this host." But, the system owner knows that the mail system is set up to log such attack attempts and drop the message. This is a false positive.

   Suppose this error came up against a web server: "The remote host is using a version of OpenSSL which is older than 0.9.6e or 0.9.7-beta3. This version is vulnerable to a buffer overflow which may allow an attacker to obtain a shell on this host." This is a serious concern. We would add this to a list for system administrators of all Linux web servers to check and fix

4. Periodically, and randomly, check systems in each category and class, checking the results against what you expect. This is different from step #3 in that we will not usually generate a "things to check/fix" list. In step 4, we’re doing spot checks — think of them as random surprise inspections.

For more information

Joel Snyder tested five VA scanners for Information Security Magazine’s March 2003 edition. Find it at http://www.infosecuritymag.com/2003/mar/cover.shtml

A search on searchSecurity.com will turn up some VA vendors. A year ago, Information Security Magazine, for whom I write, reviewed some assessment products. (http://www.infosecuritymag.com/2002/apr/solutions.shtml.) There are also numerous freely available products such as "nessus" (www.nessus.org).

Promotions, Self and Otherwise

I reviewed the Sidewinder G2 Firewall Appliance in the April 2003 issue of Information Security Magazine. Find it at http://www.infosecuritymag.com/2003/apr/testcenter.shtml.

On April 28, at Networld+Interop in Las Vegas, I’ll again be teaching (an updated) "VPN Day 1: Fundamentals" class with my pal, and fellow security consultant, Dave Piscitello ( http://www.interop.com/lasvegas2003/). I am also teaching a new course, "Advanced Firewalls," on April 29.