Re: Vulnerability Assessment

[dcdave () att net]

 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
------------------------------------------------------------------------