Re: Vulnerability Assessment

[dcdave () att net]

 Pete,

Thanks for your obviously experienced and well-considered response.

I agree with you that the 'Risk' is useful for helping make controls decisions based on budget and standards 
requirements. I helped write some of those standards (NIST, and no, it's not my fault - I was just one of a team)...

In a 'perfect' world, risk would not matter - any and every point of vulnerability would be discovered and mitigated. 
Heck, in a perfect world, the owrd 'mitigation' would not exist - instead each and every point would be 'corrected' or 
'secured'.

I also agree that every point of vulnerability should be included - even the 50 bazillion file permission problems that 
show up (and skew the automated graph reports when using automated OS vulnerability tools on an application-oriented 
establishment are worth including in the *data*.

I would suggest that one of the differentiators between an automated report and what a true, experienced vuln. ass. pro 
can offer is that of bringing some rationality to the panic that ensues in most shops when the administration sees how 
truly open they are.

I would suggest that one of the guiding factors for 'mitigation and other 'recommendations' (you know, the 
second-to-last part of a good vulnerability assesment report, not included in the automated tool returns because of the 
human judgment factor required... <smile>) is, in fact, related to actual risk. Sometimes this even has a relationship 
to any existing Risk Assesment documentation...

IMHO, therefore, I prefer to list ALL the vulnerabilities but prioritize fixes based on my perception of the risk of 
that vulnerability being exploited in that environment.

And yes - tha would include addressing the potential for damage done by accidental breached, internal and otherwise.
--
CSO 
InfoSec Group 
703-626-6516 



-------------- Original message from Pete Herzog <lists () isecom org>: -------------- 


> Hi Dave, 
>
> > 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 ), 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. 
>
> Your points before this one are well taken and I do hope some people learn 
> from the DoS mistake of yours you mentioned. 
>
> Risk is a concept for choosing security and controls. Testing, however, is 
> verifying to what level that security or those controls exist. To test, 
> you don't make a risk assessment. Doing so would restrict your findings. 
> You make a thorough test of everything within the business requirements, 
> policy, regulations, etc. Remember, you're there to make sure they didn't 
> forget anything. You can't do that if you're making the same guesses they 
> are. That's why the OSSTMM can help you not miss anything. 
>
> In terms of analysis, where you need to trust employees or not, I think you 
> make a good point about risk but it's the wrong thing to do. Even the most 
> loyal employee can send the wrong mail by accident to the wrong person or 
> be fooled into clicking on the phisher's link. You need to treat every 
> interaction on the network as one of a business perspective where security 
> provides a means to efficiency, less accidents, and a quicker reaction to 
> mistakes. In that case it's not about who you trust inside or out but what 
> you need to keep the business running efficiently. If locking down all the 
> desktops means less help desk hassles (it doesn't) versus the cost of 
> employee turn-over from unhappy employees, then make your decision that 
> way. Not whether or not you trust Alice or Jack. If you really think we 
> can make good trust choices as human beings, just watch a few daytime talk 
> shows ;) 
>
> -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
------------------------------------------------------------------------