RSnake over at ha.ckers.org discusses his ideas on a topic he calls "iterative scanning". His idea is that one should take into account what information they already know. He concludes that, during an assessment, one should not run a check for a vulnerability if you have already know that the vulnerability cannot be present on the remote server. For example, there is no reason to an exploit on an IIS server when the vulnerability only affects instances of Apache.

He's absolutely right of course. There is no reason to even try to check for an IIS vulnerability when you already know that the remote web server is Apache. A solution for this was implemented at nCircle for this problem years ago. Before checking to see if a vulnerability is present on a computer, we try to ascertain whether or not it is even possible for the vulnerability to be present on the server.

There are many advantages to doing things this way. First, it speed things up significantly. Instead of enumerating through the entire list of known SMTP vulnerabilities, you can just focus on the ones that affect Sendmail if that is what is presently running. Secondly, it minimizes false positives. There is no absolutely no chance that a check for a Postfix vulnerability will fire in the above example.

Of course, fingerprinting can be both easy and difficult depending on the protocol. However, even with the high cost of entry, the benefits to determining what is running prior to performing any form a vulnerability scan outweighs the cost. I'm really glad that others in the industry have started to get on that bandwagon.