[Dshield] Security Policy Question

DAN MORRILL dan_20407 at msn.com
Mon Aug 25 11:47:34 GMT 2003

That seems like an interesting idea,
Policy exists for a reason, delimiting behavor to that which is acceptable 
to an organization. Which is a good thing. But things I have noticed about 
policy is that people will move around it if they find it too restrictive, 
or they can not do their job, or think they can not do their job and the 
policy needs to go.

The other issue is updating and maintaining the primary policies. Usually 
they get written and rolled out with great fan fare, but collect dust on the 
SAN. Even the person who is required to maintain the policies have a hard 
time keeping up with them.

While I like the idea you proposed, what would be your approach for putting 
it into the policy life cycle at an organization.

Sometimes MSN E-mail will indicate that the mesasge failed to be delivered. 
Please resend when you get those, it does not mean that the mail box is bad, 
merely that MSN mail is over worked at the time.

Otherwise, hope things are going well.

>From: Ben Robson <ben at robson.ph>
>Reply-To: General DShield Discussion List <list at dshield.org>
>To: General DShield Discussion List <list at dshield.org>
>Subject: [Dshield] Security Policy Question
>Date: Mon, 25 Aug 2003 03:49:09 +1000
>A thought ocured to me today when considering what constitutes a well 
>crafted policy document, and I thought I would seek your input.
>When considering what makes a good policy my thoughts always go to one that 
>describes the intent and spirit of the policy, provides the reader with the 
>ability to make judgement calls against the intent and spirit, and then 
>provides specific rulling information as a kind of case-law.
>The reason for this is that I feel the average office schleb is incapable 
>of reading and hence abiding by some of the tomes that make up policy 
>documents these days, so it is better to give them something smaller and 
>more comprehensible.
>The big thing this allows however is the existence of "grey" areas within 
>the policy.  That is something that has no clear "case-law" by which to 
>judge it, and which one reader interprets as being allowed, and another as 
>not being allowed.
>To cover this I am thinking the best way is to borrow a concept from the 
>racing industry (at least this is where I know it from) in the form of the 
>"Judge of Fact".
>The concept of a "Judge of Fact" (for those that don't know) is an 
>individual or role who has the right to make arbitrary rullings on whether 
>someone, or something, by their, its, actions are in breach of a rule or 
>policy.  The outcome of this persons ruling or a review of this persons 
>ruling may then contribute to the existing policy document as further 
>case-law for future rulings.  The intent of the role is to address the 
>possibility of things falling in to the grey areas and hence being got away 
>with, and allows a ruling to be made immediately rather than through a 
>protracted process that may get bogged down in politics.
>My question to you is this.  In your opinion (and I know much of the 
>response I get will be based on U.S. law) would a "Judge of Fact" aspect of 
>an employee policy stand up to legal challenge in an industrial relations 
>(or other) court?
>list mailing list
>list at dshield.org
>To change your subscription options (or unsubscribe), see: 

Enter for your chance to IM with Bon Jovi, Seal, Bow Wow, or Mary J Blige 
using MSN Messenger http://entertainment.msn.com/imastar

More information about the list mailing list