Standard Maturity

Posted August 15th, 2007 by

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

  • 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.”

Similar Posts:

Posted in FISMA, Odds-n-Sods, The Guerilla CISO | 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: