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