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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 12:58:07 PDT