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

“QA !== Security”

I wrote that back in December on a yellow post-it and gave it to one of my contacts during some Security Test and Evaluation (ST&E) activities that were stepped on by a bazillion QA people.  He cared enough about the message to put it up in his cubicle when he moved, and it’s been warming the cockles of my heart ever since.

So why is it that today I’m writing policy and appointment letters for the Technical Review Board (TRB), Engineering Review Board (ERB) and Change Control Board (CCB)?

I’m not even remotely an Information Technology Infrastructure Library (ITIL) geek, but I do realize one thing:  I cannot keep denying changes at the CCB because it’s hurting the business side of my organization.  CCB is too late, it’s where people ask for the final approval and deconflicting of maintenance windows.

My chances at success for IT strategy depend on me getting involved in the planning stages of changes.  That means initiating the TRB, ERB, and CCB for the simple reason that I can straphang on their efforts.  In other words, I can head off security problems at the pass.

Moral of this story is that it pays to have friends in ITIL/CMMI/QA/$foo.

• A Niche to a Niche is Still Hard to Staff
• Guerilla CISO Tip: Get Inside the Data Center
• Some Comments on SP 800-39
• Rebuilding C&A
• Mike’s Guide to Information Security Policy

I’ve had 6 incidents over the past month.  Nothing earth-shattering, but it makes me wonder why so many, when I’ve been relatively quiet incident-wise for the past 6 months.

All things considered, there are 2 reasons why I’m investigating more incidents lately.

First cause is personnel turnover.  We’re a managed services provider, which means operations.  Typically, most of our slots are for entry-level server and network administrators.  We have had a high level of turnover in the past couple of months.

Second cause is me.  People now know to come to me when they suspect a security incident–my shameless internal self-promotion is working somewhat.  That means that out of the 6 incidents, there were really only 3 that were valid, the rest were just suspicious activity.

• A Visit from DCAA
• Carnegie Mellon’s Guide to MSSPs
• Turning Routers into Firewalls
• GSA Looking for a Few Good Tools
• Categories of Security Controls in Outsourcing