Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Re: Features of a vulnerability scanner

From: Anders Thulin (Anders.Thulinkiconsulting.se)
Date: Tue Dec 02 2003 - 02:02:34 CST

Marc Ruef wrote:

> 1. Which features for you are very important or is the most
>important in a vulnerability scanner software?

   I have a hang-up on the difference between enabling tools and
supporting tools: tools that only allows me to do somthing vs.
tools that support me in doing something. I prefer the latter.

   Some tools are designed by batch-programmers: you input some
data, tweak some parameters, and then press the big green button.
Then you stand back, and do very little else but watch in awe the
Scanner do its Work. (Did I say 'some'? ... I think I mean 'all').

   I'd like to see a scanner that was designed on the idea that
the computer does the grunt work -- everything that can be
automated. Difficult things -- such as reconciling fingerprints
that indicate that the system is a Xerox printer, a Win95
box, a Linux 1.1 system and an IP-telephone at the same time --
should be possible to leave to a more competent brain.
I'd like the scanner to behave as a servant, not as a replacement.

   Also, it allows me to modify it to my own purpose, and preferrably
also lets me build my own tool structure inside it, or around it.
Open data storage is one very important item here.

   (Yes, that last item is wishful thinking.)

> 2. Which features are you missing in the existing vulnerability scanner products?

   I can't say this is missing in *all* products, as I haven't
used them all. But those I have used have left me wishing for more.

* Traceability and accountability.

   When the scanner reports that the remote system runs finger, but
I can't find a trace of one, I want to be able to see what input
it was working on and how the decision process happened. (I also
want to be able to add, modify or delete such vulnerability entries
myself.) One scanner used to report open rlogin + empty root password
for tcp-wrapped rlogins -- probably because the response from wrapper
didn't match any string in it list of 'you're not allowed to enter'

   When an irate customer calls, and asks if I am responsible for
an important system crashing on them, I want to be able to see
if I/the program did something against that system reasonably shortly
before it crashed, and also what it did.

* 'Full disclosure'

   The scanner should not impose *any* policy of its own. One scanner
let me know that it had cracked two user passwords on system A,
but not anything more than that (the documentation indicated
it was deliberately suppressing information because of security
risks). Unfortunately, that system held more then 60 users. We had
to change all passwords, and so were unable to figure out whose
passwords and how the password policies had been bypassed.
(Traceability comes in here as well: I have a suspicion the scanner
may have misinterpreted response data.)

   If there is a need for policies, it should be possible to
let them be my policies.

* Adaptability

   I want to be able to add my own tests, preferrably coded in a
language I know. That is, some kind of plug-in architecture with very
clean and architecture-independent interfaces.

   In this area comes internal adaptability as well: some scanners
report that system X must be a Windows, because of, say, ICMP
peculiarities, then decides that it must be a Linux system,
because of some port characteristics, and finally decides it's
a printer, because of some SNMP peculiarities. For some reason
they can't accomodate all these possibilities at the same time,
and so flag the system as 'peculiar -- needs better eyes than mine'.

   This 'allow and support the user to retest and adjust scanner
findings' is probably the top item on my list.

* Not 'Everything in one'

   I'd like to see scanners that show some kind of architecture.
A program that both a host scanner, and a vulnerability scanner
as well as a reporting tool is probably deficient in at least
one of these areas -- most often the reporting part.

   But then I do pen-tests professionally. A beginner would look
for quite different features.

Anders Thulin anders.thulinkiconsulting.se 040-661 50 63
Ki Consulting AB, Box 85, SE-201 20 Malmö, Sweden