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

Good things are afoot.  DISA has a SRR Lite CD that has all of the tools that you would need.

• Our “Peace Dividend”: DISA SRR Scripts
• My Inbox this Afternoon: Best Practices Checklist
• GSA Looking for a Few Good Tools
• Save a Kitten, Write SCAP Content
• Evolution of Penetration Testing: Part 1

In my somewhat hazy job description, there is one additional duty that I have absorbed:  limited asset management.  As I tell people all the time, I’m not an asset manager, but I become one when I have to.  For example, I spent an entire month last year doing equipment inventories.  Not a thing to be really proud of, but at the time asset management was one of the chief risks that my organization faced.

My CISO trick for the week:  Know where the engineers hide the excess equipment.  Every NOC, SOC, and data center has the place where, when equipment is missing, that’s the place where you can go and find it.  In the NOC, it’s the closet in Eric’s office where he now has 6 managed switches and some other networking gear.  In the SOC, it’s their half-rack worth of lab equipment, including some spare firewalls and IDS sensors.  In the data center, it’s the top half of rack 1-2 where the engineers put equipment and lock it up so it won’t walk away.

Point is, most organizations have these hiding places, and it’s almost an unwritten duty description to find them.  Don’t point them out as I just did, but keep them as your little secret and when you need to either find something that is missing or absolutely need a piece of equipment, you can go check the usual places and see if you have one on-hand that is not being used.

Last week I told one of our projects that they could not open up some services across the Internet until they designed their connections right with a DMZ for the Internet-accessible servers.  We left the conversation with a logical diagram to build from and the need for a firewall and a small switch–loaner equipment to get them up and running right now and that they could replace with their own when they ordered replacements.  10 minutes later, the project team had a PIX and an older catalyst, all culled from hiding spots.

One final thought for today:  I call these places “Mike’s Happy Hardware Hunting Grounds”. =)

• The Guerilla CISO
• Government-Wide Monitoring? ‘Bout Time.
• Lions, Tigers, and VLANs Oh MY!
• Guerilla CISO Tip: Get Inside the Data Center
• Government Can’t Turn on a Dime, News at 11

In a news article at The Register, the US Government is going to have a standard hardened set of settings of Windows OS’s that they will require vendors to install.

From TFA:

“The purchasing power attached to the $65bn federal IT spending budget means that suppliers will have no choice but to take notice.”

Right on!  I’ve been waiting for this for a long time.  You have the 8000-lb gorilla of IT budgets sitting back, buying all this junk from people and then not doing anything about the poor quality of it.  About a year ago, I started teaching government employees in my classes that they had the power to ask for better software, and I think the idea is starting to sink in.

Now they have to do me proud and not make the settings a watered-down weak version of what they should be.  My one fear is that this will be hardening by committee, where you have all these people who show up out of nowhere to complain that one hardening setting or another breaks the functionality they absolutely need to not harden that part of the OS.  The problem with that is you end up with hardening holes.

• Do You Know What FISMA Is?
• Rebuilding C&A
• Power Outages Do Happen
• And Now for Something Completely Different…
• SCAP for Dummies