I had a friend, Mr Vlad the Impaler of blog comment fame, who sent me this article: 10 Pieces of Lousy Security Advice.

Numbers 1 and 4 (IIRC) are my favorite whipping-boy, c*mpliance. Yes, it’s lightweight reporting and fairly obvious to security dweebs, but it brings a tear to my eyes. =)

• Bacn–It’s Cooked Spam
• On Government Employees, Culture, and Survivability
• When the News Breaks, We Fix it…
• It’s a Blogiversary
• Managing Security in Large Organizations

Yes, I think I got Rob Newby hooked on saying the “C-Word”.  Now if he says  in on the BBC and I get a recorded version of it in my email, I’ll die happy.

I would like to think I was the first person in the world to use this phrase, but then again, I like to think I started the whole “Long Tail of Security” that people have been talking about this week thanks to Mark Curphey.

Another phrase that I want to popularize in addition to the “C-Word” is “C*mpliance” as in how it’s a dirty little word to say around me.  This isn’t entirely my idea, I got it from the Hashers who use the word “r*nner” to describe those daffy people who think that if they don’t go faster, the beer will be gone before they get there.

It’s the little things that make me happy sometimes.  Having people start talking like me is one of them.  =)

• The Guerilla CISO
• Create Your Own Apple Rumors
• Some Thoughts on Comments to My Blog…
• A Day in the Life of the Feedmaster
• Blog Statistics and Search Strings

AC-23 Self-Destructing Mobile Devices
Control:
The organization equips all mobile devices with self-igniting devices so that they are destroyed upon command.

Supplemental Guidance:
Contrary to what Adam Shostack believes, data breaches are not good for the US Government. Therefore, it is of the utmost importance that we not allow a data breach ala VA, TSA, and others.

Control Enhancements:
(1) The organization configures mobile devices to be destroyed when they are outside of a government facility. (2) The organization configures mobile devices to be destroyed when they are outside of arms reach of the registered owner. (3) The organization configures mobile devices to be destroyed at random to discourage users from putting data on them.

Low: PS-9 Moderate: PS-9(1)(2) High: PS-9(1)(2)(3)

• Yet More Security Controls You Won’t See in SP 800-53
• Security Controls You Won’t See in SP 800-53
• Super Secret Security Control You Were Never Meant To See
• Life in a Zero Defects World
• Core Belief #4 — Compliance is a Dead-End

Earlier this week, I got a 3-year-old System Security Plan (SSP) in the mail from one of my customers wanting me to update parts. My first response was “cute, we don’t really do that free-form style of document munging anymore,” followed up with “how do you expect me to discuss that ‘during an earthquake the building might have more load on it than it is designed to hold'” and then “What value do we get out of this exercise?” The translation into non-government speak is the following:

• The format is free-text
• The SSP was a rehash of contractual requirements and how they were satisfied (not a bad idea for a start, but it doesn’t answer the rest of what we need)
• The SSP was written before we had a catalog of controls (SP 800-53)
• Most people nowadays use the catalog of controls as the outline for most of the SSP

For its time and place, the SSP was correct, but it seems so quaint 3 years later. Naturally, this got me thinking about maturity of information security standards. What I’ve seen is that for any kind of a standard, there is a cycle:

• Initial Release: Standard is published, everybody has a look at it.
• Early Adopters: Something nobody wants to be. These people waste tons of effort because once they go in a direction, the standard will change. Bottom line is lost time, effort, and money to be an early adopter. Reminds me of the old saying “How can you identify the true pioneers? They’re the ones with the arrows sticking out of their backs.”
• The Intermediaries: These people get to help write the implementation guidance for the standard. They are similar to the Early Adopters except they are more careful and don’t commit to large changes unless they have them adopted into the guidance.
• The Hoi-Polloi: Once the standard is mature (or perceived to be mature), the rest of the masses will commit to the standard.

Now the trick here is to be one of The Intermediaries because they get to come in and help define the standard. If you make the standard, then you automagically have achieved “compliance”. I think the big difference between being an Early Adopter and an Intermediary is how much time and effort you have to spend to teach the enforcers of the standard what your “Level of Pain” is and where you’re having problems doing what it is they’re asking you to do.

In the case of my aforementioned SSP, it bordered on Early Adopter and Intermediary. but how do you conform to a standard that’s still being written? It’s an interesting conundrum, and one of the contradictions of security in the government that we discuss when I teach.

Strangely enough, this cycle applies to just about any technology or standard, underlining my core belief that security is no different. My thought for today is this: if life imitates art, and security imitates life, then does security imitate a subset of art?

Jokingly, I think it’s more like the Kübler-Ross Grief Cycle (copied from changingminds.org):

• Shock stage: Initial paralysis at hearing the bad news. “They want us to do what?”

• Denial stage: Trying to avoid the inevitable. “This doesn’t really apply to us, we just make Frobulators, not Thingamajigs.”

• Anger stage: Frustrated outpouring of bottled-up emotion. “No fscking way are we going to do it, you can’t penalize us enough to compensate for us not doing it.”

• Bargaining stage: Seeking in vain for a way out. “How about if we give you a SAS-70 instead?”

• Depression stage: Final realization of the inevitable. “How are we going to get this done, it’s too much, too expensive, the end is NEAR!!!”

• Testing stage: Seeking realistic solutions. “So what level of compensating controls can we discuss?”

• Acceptance stage: Finally finding the way forward. “OK, we might as well get a project started.”

• It’s All About Common Controls!
• Selling Water to People in the Desert
• An Open Letter to NIST About SP 800-30
• Guerilla CISO Tip–Avoid “Boilerplate”
• In Search of a Better Catalog of Controls

I’ve been sitting in some vendor presentations lately–I think they invite me along so I can be the resident curmudgeon–and I’m starting to get a good feel for what both the government and myself want in a product.

I want to know how a tool fits into my IA framework. That framework for me is NIST SP 800-53. One side effect of 800-53 is that I can’t justify a product “just because”–I have to state how this tool or service will help me attain “compliance” with the minimum baseline of security controls. It’s not enough anymore to just say “hey, our product helps you with SP 800-53 controls, have some magic FISMA Fairy Dust“.

Advice for vendors: take the day of effort to provide a traceability matrix for me. What I have is a Plan of Actions and Milestones (POA&M) that requires me to implement the following controls:

• AC-11 Session Lock
• AC-12 Session Termination

Now what I want is for your product to say the following:

• AC-11: Our product locks out users after 15 minutes of activity on their Frobulator workstation.
• AC-12: Our product terminates users after 25 minutes of activity on their Frobulator workstation.

If your product doesn’t do a control, don’t mention it. But by all means get somebody who routinely works with the catalog of controls to determine if you meet the control objective: there’s nothing I hate more than trying to understand how somebody stretched their interpretation of control objectives that I now have to turn around and rationalize to an auditor. It’s OK if your product doesn’t do everything as long as it does the right things.

Now the reason I bring all this up is that I, too, am a vendor–a services/outsourcing vendor. I’m taking the time this week to do my own traceability matrix that says something like this:

• For the Basic Hosting Service, these are the controls that you get (mostly Physical and Environmental Protection (PE) and Media Protection (MP) )
• For the IDS Monitoring and Management Service, these are the controls that you get (mostly Audit (AU) controls with a smattering of Incident Response (IR) controls)
• For the Network Monitoring and Management Services, these are the controls that you get (hardly any except for availability monitoring)
• This is what we provide for support when you do a risk assessment or certification and accreditation
• Some controls are Inherent Government Functions (IGF) and cannot be outsourced to us such as FIPS-199 categorization and risk acceptance

The whole idea is to delineate the responsibilities for pre-sales work so that when somebody contracts with us, they know the Government’s responsibilities, our Project Management Office’s (PMO’s) responsibilities, and my operations group’s responsibilities. It’s going back to the nature of outsourcing and the fact that transparency is key.

• Categories of Security Controls in Outsourcing
• How I Do the “FISMA Thang”
• You Didn’t Outsource Your Responsibilities
• Keys to the Outsourcing Kingdom
• Reinventing FedRAMP

I helped give our auditors from the Defense Contract Audit Agency (DCAA) some education on how managed services work. We did the usual presentation–who the building tenants are, what takes place in the various floors, and what services we offer.

In case you’re not familiar with DCAA, the basic rundown is that they are the financial auditors for government contracts.  They look at your numbers and try to detect how and where you are committing financial fraud.  In our case, we have distinct service descriptions and a set of financial and operational metrics to support  the numbers (ie, each server requires 1 hour per month on average to do patching and fix outages, so the cost to us is $100, add your markup and that’s the cost per month to monitor and manage a device).

This is risk management through education for us.  When you have auditors who don’t understand why an IT operations shop would need 13K gallons of diesel fuel (I thought you did IT?), the least you can do is to educate them.

• Combatting Tool Creep
• NIST and SCAP; Busting a cap on intruders Part 1
• Reinventing FedRAMP
• Rebuilding C&A
• Guerilla CISO Tip: Get Inside the Data Center