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.

• Response to “What is Information Assurance – The Video”
• Yet More Security Controls You Won’t See in SP 800-53
• Security Assessments as Fraud, Waste, and Abuse
• Some thoughts on QA
• An Open Letter to NIST About SP 800-30