What's in a security policy? (was Re: How do we do our job?)

[Bennett Todd <bet () rahul net>]

1998-04-30-11:28:08 Darren:
> 1998-04-29-17:05:16 Bennett Todd:
> > 1998-04-29-16:01:00 Darren:
> > > So what ?  Who's verified that your security policy is any good?
> >
> > How do you verify a security policy, anyway? Since a security policy is
> > just a written cache of decisions you've worked out the hard way (by
> > analysis and negotiation) it comes to, how do you verify a
> > decision-making process? Rotsa Ruck. Gotta have one to get the job done,
> > no way to prove you're doing it right.
>
> You write down why you make decisions, for a start.  I know lots of people
> in this industry hate documentation (for one reason or another), but if
> you were to leave and someone else picked up your security policy and
> said "why is this here ?", they should be able to find the answer right
> there too and not feel like "well, I don't understand this, I want to
> change it so <delete>".

Absolutely. A written security policy works as a cache for the security
decision-making process. Making security policy decisions is _hard_; it
requires weighing perceived risk (liklihood of a vunlerability being
exploited times cost if it is successfully exploited) against benefit
(utility of a service to the organization), given available facilities
for securing a service. So when you do finally settle such a question,
you write down the factors that contributed to the decision and the
business grounds for arriving at your conclusion; this is the meat of
your security policy, and makes a valuable reference (precedent) for
future decision-making.

Intrinsic to all this is the notion that a security policy is a vital,
evolving document. In particular it should describe its source of
authority (who approves decisions), which in turn implies the needed
relief proceedure if someone wants the policy revised.

So when someone comes to me and asks for a facility that's prohibited by
policy, I start by explaining why the policy was set, and who approved
it. Then I explain what alternatives we can offer that may help achieve
their desired end. And if that doesn't leave them completely content I
explain the revision process to get the policy adjusted to suit their
wishes.

Do this consistently and the people affected by the policy come to
understand why it's there, and support it. This is the only way you
stand a chance of getting your job done.

But none of this comes near addressing the point you raised: how would
you go about ``verifying that a security policy is any good''? It seems
to me to do this you'd have to retain someone more skilled than yourself
at security-policy-making, and have them repeat the process from
evaluating organizational risks and available resources through weighing
risks and threats --- re-do your job and see if they arrive at the same
place. Does anyone actually do this?

-Bennett