Re: Vulnerability Assessment

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@xxxxxxxxxx>: --------------


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

Relevant Pages

  • RE: Re: Microsot Liability for vulnerabilities
    ... At the risk of taking this off on a tangent and/or getting kicked out of the ... Subject: Microsot Liability for vulnerabilities ... NOT EVEN KNOWN to the public for various reasons (i.e. Microsoft won't ... think that blaming it on the hackers is going to stop all software bugs? ...
    (Security-Basics)
  • RE: assessing IIS 5.0
    ... I thought you were doing a risk evaluation, ... vulnerabilities need to be accounted for ... internal IP address is a "systems configuration information disclosure, ... Without understanding the security policy of the system being evaluated ...
    (Pen-Test)
  • Windows Buffer Overflows
    ... "While many may believe that the risk for these types of vulnerabilities is ... The recent .asp exploits that I have seen all work in a similar way. ... which is a static memory address ...
    (Bugtraq)
  • Windows Buffer Overflows
    ... "While many may believe that the risk for these types of vulnerabilities is ... The recent .asp exploits that I have seen all work in a similar way. ... which is a static memory address ...
    (Vuln-Dev)
  • Re: Vulnerability Assessment
    ... 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. ... 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. ... If locking down all the desktops means less help desk hassles versus the cost of employee turn-over from unhappy employees, then make your decision that way. ...
    (Pen-Test)