I agree that knowledge is important.
Any product or tool that is used can only matter if the user understands it and
the environment it is used in.
I once was conducting a vulnerability scan on a network which I initiated with
a ping-sweep in the middle of a busy afternoon. The network crashed - it was a
Token-Ring network (I know, this how long ago my experience started!) and was
already fully saturated by running daily business AND transmitting automated
backups (huge volumes of data) to the storage site. Another time, I ran an
automated scanner with OOBS checks on a network that actually still had Windows
98 systems attached and in use for important business - pandemonium ensued.
Although the point was made that 'the window was breakable', the customer would
have had less expense in time implementing roll-backs in database transactions,
lost business, and time restoring from backups if I hadn't just walked in
'swinging the hammer'.
Another point with automated tools is understanding how it is obtaining it's
data. Things like 'watermarks' in IDS/IPS systems also translate into scanners;
setting the number of authentication attempts correctly for a net login or an
FTP or SAMBA connection or other authentication schemes which do not
necessarily go through USER PASSWORD authentication filters can make the
difference not only with success or failure, but also with 'noisy' (detected)
or 'quiet' (undetected) scans.
It is frightening to find how many 'pen testers' and 'vulnerability scanning
personnel' do not know how to appropriately tailor scnning tools to do the
correct job, or use the custom code stubs for exploits and/or responses which
are available in most products.
A final point is that concentric layers of protection have to be understood
from a risk perspective; in that a vulnerability which requires local login to
exploit, or physical presence (ALMOST ANY MACHINE) may be more or less at risk
if the employees are trusted and trustable, and the physical access is more ore
less controlled. In other words, if a Financial Server or Top Secret Server is
running an MS Operating system (already a questionable practice <smile>), and
is protected behind umpteen firewalls, AV, IDS/IPS, it may be more vulnerable
if any joe could just walk up to it physically and do something like boot it up
on CD (BackTrax it) or less vulnerable if there is no unauthorized physical
access and the keyboard and monitor are controlled.
These are just a few of hundreds of examples of what a vulnerability
assessment, IMHO, should be able to addressas required....
dcdave
Dave Druitt
--
CSO
InfoSec Group
703-626-6516
"Using words to describe magic is like using a screwdriver to cut roast beef"
-Tom Robbins
"There is a big difference between kneeling down and bending over" -Bob Dylan
-------------- Original message from Pete Herzog <lists@isecom.org>:
--------------
> Hi John,
>
> > I find that vulnerability scanners are useful when they can do credentialed
> > scans to verify that the services are actually running and check patch
> > levels based on current patch data and such. Nessus in particular is good
> > for this, and it also allows you to use it for configuration validation as
> > well provided that you pay for the commercial feed. There are limitations
> > though.
>
> I agree that Vulnerability scanners can be useful if it is the answer to a
> question. The problem is many people start with the VS as the question as
> if it's a necessity. Scanners have evolved through marketing to being the
> means to a vulnerability assessment rather than a tool of one. Maybe it's
> the "final" report that throws so many people off-- that once the report is
> generated the work is done and not just the job.
>
> >
> > Depending on what you find and the policy you are being held to further
> > validation may need to be done, but I think they're at least a good
> > starting
> > point as long as you know its not 'point-click-and-ship' and the report is
> > gospel.
>
> I think just popping the results of nmap, hping2, hydra, unicornscan, and
> netcat into a database and correlating the results is the basic starting
> point and alone provides a lot more value than the vulnerability scanner.
> But this is for people who ask the right questions of their data. It also
> requires the ability to make a security analysis of the data- which is not
> too much to ask for from an IT security professional, right? Which is why
> so many members of the OSSTMM community pushed us to start the OPSA five
> years ago. It's a basic thing to know what you're asking for out of your
> tool data and not just happy with what the tool is telling you about it in
> a report. Even if that tool is a scanner.
>
> You know many IT security professionals can't even tell you why Nessus runs
> a traceroute to each and every host in the list. To them it's just another
> thing in the report because Nessus didn't say why it was doing it. I
> haven't seen the newest versions of Nessus lately but I wouldn't be
> surprised if now they said on the report as to why.
>
> >
> > Nothing is better than having the ultimate validation: actual exploit of
> > said vulnerabilities and having nc running on a host listening for you're
> > every command ;-) The only issue is you're bound by policy there as well.
>
> Even verification, or ultimate validation, is not necessary if you don't
> have a problem that requires this type of verification. You don't need to
> break a window to tell people it could be broken. However, if the
> investment is in an unbreakable window, then you can't walk away without
> swinging a hammer. Vulnerability assessments are the same. Not all bugs
> will be patched because most are already mitigated through architecture
> changes, shutting down services, and various controls. Not all bugs matter.
> Realistically, very little needs to be exploited to prove a vulnerability
> assessment. An exploit is only if you have to prove penetration. To even
> use it to prove that a patch is applied is nonsense because you can only
> prove that the exploit still works despite patching because if it doesn't,
> you have only proved that the exploit did not work for you. It can't prove
> a patch.
>
> Sincerely,
> -pete.
>
> ------------------------------------------------------------------------
> This list is sponsored by: Cenzic
>
> Need to secure your web apps NOW?
> Cenzic finds more, "real" vulnerabilities fast.
> Click to try it, buy it or download a solution FREE today!
>
> http://www.cenzic.com/downloads
> ------------------------------------------------------------------------
>
------------------------------------------------------------------------
This list is sponsored by: Cenzic
Need to secure your web apps NOW?
Cenzic finds more, "real" vulnerabilities fast.
Click to try it, buy it or download a solution FREE today!
http://www.cenzic.com/downloads
------------------------------------------------------------------------
|