RE: Fwd: Article Announcement - Demystifying Penetration Testing

["Vic N" <vic778 () hotmail com>]

> Nice, but it doesn't cover the "So what?" question.
>
> If a CEO asks you, "So you broke into my systems, so what?", how do
> you answer that question?  When you first sit down with a company to
> discuss what you are planning on doing, you should ask them what is
> critical to their company.  Have them list what is critical to their
> company that would adversely affect them if that information became
> public or ended up in the hands of their competitors.

I have thought about this question for a few days, and I'd like to make a 
comment.  What is being said is a very valid point.  I have been asked many 
times to articulate the significance of a vulnerability assessment or 
exploit.  One person even dared possible intruders to make heads or tails 
out of the million plus lines of code that a potential intruder might be 
able to examine.

I think one needs to start with a client's identified concerns but should 
then also be able to identify areas that might not be obvious to a client as 
potential sensitive areas.  For example, maybe I can't get to your source 
code, but I can get to your voip voicemail or backups of source code.  It 
seems important to be able to show a client / boss the areas they haven't 
considered.  Who can know all possible motivations?

More pertinent seems the idea of -  The issue isn't whether you see this as 
a vulnerability but can you explain your decision not ot act on a possible 
exploit to your stockholders?  Granted, one eventually approaches the apex 
of diminishing returns, but there how soon?

I am sure we all undersstand this to be obvious, but I mention it because I 
see so little reference to the idea of policy and procedure.  I could be 
totally wrong here (and I flinch stating it the list), but I think the 
average CEO does not have the luxury these days to say "so what"  in the 
face of the likes of  the Sarbanes-Oxley laws (which very crudely put) holds 
executives responsible for short-comings on their watch.

Doing a vulnerability assessment against a company's stated corporate 
computer/network usage policy might facilitate a very useful dialogue 
between a client and auditor that would enable them to really address legal 
and pragmatic concerns together when evaluating security concerns.  It seems 
reasonable to also ask a client to provide their written policy on 
network/computer usage, not just what they think is valuable, but what they 
have committed to paper as being valuable during an audit.  As an auditor, 
if you have a written policy to evaluate, you also have to spend less time 
qualifying your findings if the findings contradict written policy.

The ultimate "get out of jail free" card for an executive seems to be rooted 
in the idea of solid policy more than anything else.  As a consultant, one 
might consider this Machiavellian to zoom in on policy flaws versus "real" 
flaws, but I do not think so.  A well-defined policy gives a lowly sysadmin 
the ability to act without having to be in conflict directly with each user 
(i.e, be effective in being able to remediate w/o high level intervention).  
It also indicates that a mangement team has put forth its best thinking on 
any identified topic.  That is significant.

I don't mean these comments as a cheap shot against a valid post, because 
it's very useful to know a client's concerns, but it seems that it's more 
the aspects that a client hasn't considered that need to be addressed.  And 
a written  policy is a good way to state intention and should be a starting 
point (it's practices and implementations that ultimately protect a 
network).  Being able to identify who is responsible for what at each level 
fo the "food chain" seems an ultimate approach to effective security for 
computer networks.

Just my $.02.