Security Policy (was Re: how to do intrusion detection right)

From: Bennett Todd (betat_private)
Date: Wed Apr 15 1998 - 04:03:54 PDT

  • Next message: pybat_private: "Domino/NOtes anti-spamming"

    > Here I'm not using "policy" in the usual computer security sense,
    > of an unyielding set of rules; perhaps it's more an intent of
    > what should and shouldn't be going on.
    
    I've worked in one shop where the Data Security Department suffered
    from the delusion that a security policy can or should be an unyielding
    set of rules. That was maybe 8 years ago, all the major staff of that
    department are blessedly gone, and as far as I know the damage hasn't
    been undone yet; if any security work is accomplished in that firm
    it's not done by the Data Security department, as the people in that
    department gave it a reputation for being utterly useless, and mildly
    destructive if not ignored.
    
    I've since had some wonderful good fortune. I came to work at a shop
    that had intelligent and wise management, and then saw another example
    of the same at a truly superb ISP. In the _good_ places I've had a
    chance to see a Policy as a kind of a cache: decision-making is _hard_,
    so whenever you work through a meaty one, make a note of the
    circumstances that seemed to guide the decision and the conclusion you
    came to, and lean on precedent in future decision-making.
    
    When you view it that way it becomes obvious that a Policy is a living
    document. This has enormous value.
    
    The most tricky and delicate part of security administration is getting
    the users to support the policy. The first part of dealing with this
    comes as you're formulating the policy, but the ongoing work comes in
    selling it. Typically a user comes and says they want to do something,
    and they can't, please fix it. What they want to do (e.g. view a web
    page with applets) is prohibited by the policy. So you explain to them
    why the policy is as it is, what the cost to the organization would be
    of relaxing the policy. You try to find an alternative way to meet their
    needs. And you pitch your explanation of why they can't do what they
    asked in such a fashion that they know who they'll have to approach, and
    what argument they'll have to overcome, to get the policy changed to
    suit them.
    
    Do this right and the user community comes to really actively support
    the security policy; then you can start doing your job _right_.
    
    -Bennett
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 12:54:36 PDT