RE: Fwd: Article Announcement - Demystifying Penetration Testing

From: Vic N (vic778_at_hotmail.com)
Date: 12/14/04

  • Next message: Gareth Davies: "Re: Research on penetration testing?"
    To: pen-test@securityfocus.com
    Date: Tue, 14 Dec 2004 06:27:39 -0800
    
    

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


  • Next message: Gareth Davies: "Re: Research on penetration testing?"

    Relevant Pages

    • Re: GPO causing client security logs to fill?
      ... a virus in play. ... settings to be applied on your client workstations. ... Group Policy is a complex and often misunderstood beast. ... I modified the account ...
      (microsoft.public.windows.server.sbs)
    • Re: GPO causing client security logs to fill?
      ... titled "Client Logon Failure". ... This was done in the Group Policy ... So basically, the Account lockout threshold, account lockout duration ... When you do clean boot on the client computer, ...
      (microsoft.public.windows.server.sbs)
    • Re: Group Policy access denided
      ... Group Policy processing aborted. ... DFS client to make a connection. ... File and Printer sharing, netbios, etc) and firewalled the external network ... NT or Windows 2000 to Windows 2003 Server. ...
      (microsoft.public.backoffice.smallbiz2000)
    • Re: GPO causing client security logs to fill?
      ... titled "Client Logon Failure". ... This was done in the Group Policy ... So basically, the Account lockout threshold, account lockout duration ... of the client computer have several logon failures through a day. ...
      (microsoft.public.windows.server.sbs)
    • Re: GPO causing client security logs to fill?
      ... titled "Client Logon Failure". ... This was done in the Group Policy ... So basically, the Account lockout threshold, account lockout duration ... When you do clean boot on the client computer, ...
      (microsoft.public.windows.server.sbs)