RE: [IDS] IDS Common Criteria

From: Graham, Robert (ISS Atlanta) (rgraham@iss.net)
Date: 01/17/03

  • Next message: X-Force: "ISS Security Brief: PeopleSoft XML External Entities Vulnerability"
    Date: Fri, 17 Jan 2003 13:37:07 -0500
    From: "Graham, Robert (ISS Atlanta)" <rgraham@iss.net>
    To: "Randy Taylor" <gnu@charm.net>, <focus-ids@securityfocus.com>, <ids@mailman.vet.com.au>
    
    

    From: Randy Taylor [mailto:gnu@charm.net]
    >I agree with you that CC and a process-oriented security approach
    >are different "things" in and of themselves.

    They are the same. It seems you haven't understood either of my previous
    messages (sorry, I probably phrased them poorly).

    My argument is essentially: Common Criteria Evaluation is an example of
    good process, but it is generally bad -- therefore process is generally
    bad.

    When cryptographers say "security is a process", the type of processes
    they are referring to are those like Common Criteria Evaluation. I have
    a hard time understanding how somebody can be "for" process, but
    "against" processes like CC.

    The crux of the problem is what economists call "decreasing marginal
    returns". A small amount of lightweight processes give you more benefit
    than they cost. A large amount of heavyweight processes (like CC) give
    you marginal benefits but cost a huge amount. If you are the military or
    intelligence organization (the guys cryptographers generally design
    cryptography for), then you are willing to spend that much for small
    improvements. If you are everyone else, then you can't afford it. The
    military has secrets that are worth more than your entire organization
    (and you don't).

    A small amount of process is worth the cost. However, many have jumped
    on "security is a process" in order to burden their organizations with
    overweight processes. Moreover, narrow minded bureaucrats often use
    "security is a process" to prevent talented/educated people from
    actually getting their job done -- with a detriment to an organization's
    security. I see organization after organization where process is the
    enemy of security.

    Disagreement on semantics is one of the most boring debates on
    technology forums. It is quite possible that you and I agree on the core
    problem except for the semantics: i.e. you describe reasonable processes
    and express a distaste for heavyweight processes. My goal isn't to
    convince you of my semantics. My goal is to give ammunition to the
    talented security engineer who is stopped by stupid people who insist on
    controlling their actions with yet more process, because Bruce Schneier
    says that process is the end-all/be-all of security. I find it curious
    that there are lot of people who know little about security, yet they
    insist that they should be the ones creating more process to constrain
    the actions of those who do. I have met a lot of frusterated security
    professionals out there who have expressed these same sentiments.



    Relevant Pages