Mike’s Guide to Information Security Policy

Posted April 3rd, 2007 by

It’s a little-known secret that will get out fairly quickly:  I hate security policy.  I hate writing it.  I hate having to live with other people’s security policy that is just a rehash of the NIST guidance in new packaging.
In light of this, I’m offering up to the world “Mike’s Guide to Information Security Policy”.

First, policy only works when it’s grounded in reality.  That’s why, just like Ludwig Mies van der Rohe, I believe that “less is more”.  Something big and theoretical is OK, but what the server team manager needs is a “how-to” process and checklist for firing an employee without creating an incident.

My policy framework looks roughly like this:

  1. Overview:  We like information, it helps us do our job.  The CISO is responsible for creating policy.  Senior Management signs the policy.
  2. Risk Management:  We will make cost/benefit/risk comparisons.

The rest is details, and it’s easy to have a skeleton for each control family from whatever framework you want–PCI, 800-53, SoX, 7799, etc.  I use 2 frameworks: 800-53 and ITIL, although sometimes I run into other areas that are normally QA.  I’m not the ITIL policy person, but I realize that if I want to succeed at the information security approval at the Change Control board, I need a Technical Review Board and an Engineering Review Board.  That keeps me from denying changes at the last minute because if I do that, I hurt the business end.  I would rather shape the change further upstream so that it becomes easy to approve at the end of the process.

My rule of thumb on policy is that if I have to make a decision on something 3 times, then it needs to be written down in a policy because there are more people that need to ask but haven’t.

Similar Posts:

Posted in FISMA, NIST, Rants, What Works | No Comments »

Leave a Comment

Please note: Comment moderation is enabled and may delay your comment. There is no need to resubmit your comment.

Visitor Geolocationing Widget: