I bet nobody ever thought a System Security Plan would end up getting released to the world through a FOIA request.

Comments on the documents:

• The CI-100 DCS-3000 to EDMS System Security Plan is a little odd–why not just make it an interconnect document instead of a full SSP?  It’s just a strange way to manage things in my mind.
• The SSP, even though it’s from 2007, is way “old school”.  It doesn’t follow along the SP 800-53 catalog of controls that is pretty much down to a formula nowadays.  I guess the tech version is that the document has bit rot.
• The SSP details a technique to take a live feed of unclassified data and pump it into a classified system through a one-way serial cable (RS 232, remember what those are?)    =)   At any rate, it should be an interesting technique if you’re not used to dealing with that kind of interconnect.
• The Risk Assessment doesn’t describe what I would want to know, and that’s really the heart of my first comment.  Basically what I have is 2 systems that are connecting to each other, so what I want to know is what are the risks associated with each side and what is the risk of the interconnect itself.  Each side has their own security plan, so that’s why it’s an interconnect instead of a SSP.  But we haven’t addressed the security controls of the connection itself.
• There are some other minor annoyances, like “why are you grading the system on your ability to install ISS System Scanner” but I’ll leave those for you to go discover. =)

Have I jumped completely over the edge?  I think I have. =)

• One Catalog to Rule Them All
• Remembering Accreditation
• Feds to Embrace SaaS, End is Nigh for Security!
• Rebuilding C&A
• An Open Letter to NIST About SP 800-30

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 promised myself I would stop with the vendor bashing at least long enough to catch my breath. Well, sometimes in your life something comes along that you just can’t help but comment on.

Press release on how a network emulator can help with FISMA reporting.

This class of products is great–simulated network lag so you can test your network devices, software, etc. Every lab should have this stuff.  I’m pretty sure that some of it is inside my building in the various replicas of customer networks that the engineers use.

But what does this have to do with information security management? Once again, it’s sprinkling the magic FISMA fairy dust and wishing that it makes your product a security device.  Makes me had the”make it secure” wand (complete with star on end and ribbons) that one CISO I know of carries about just for the purpose of being able to wave it around and say “*Poof* It’s secure now.”  I figure happy thoughts are in there somewhere, but I’m just not seeing the exact mechanism.

My friends have a theory that I should start selling SOX socks and FISMA underwear. I’m not so sure about that, but I figure if it works for all these other products, it might be a massive moneymaker for me.  =)

• Do You Know What FISMA Is?
• Blog Statistics and Search Strings
• Selling Water to People in the Desert
• On Why I Blog… FUD is the Reason for the Writin’
• Digital Forensics: Who should make the keys?

It seems like every product or service that somebody is trying to sell me has the words “bank” or “financial institution” attached to it. The cynic in me would say that either the SOX cash cow is drying up and the vendors are trying to glom onto FISMA, or the only past performance that these small-fry vendors have is with a bank that bought their solution once.

Part of me also wants to know if banks will buy whatever junk I throw at them. =)

So is the secret to selling a product to the government a cleverly crafted Unix shell command like the following:

cat marketing.literature.sox.txt \

| sed ‘s/SOX/FISMA/’ \

| sed ‘s/bank/government agency/’ \

> marketing.literature.fisma.txt

You would think so based on the spam I get nowadays. It’s so obviously retreaded that I keep wondering “Do you guys even believe your own literature and hyperbole about what you’re trying to sell?” I don’t expect sales people to be the experts at my business, but how can you offer me a solution to my problems if you don’t understand the gist of what my problems are? If you don’t know that bank security is primarily modeled on integrity and that government security is primarily modeled on confidentiality, then we don’t really have a common language.

My vendor spam for today is below. “Compliance as a Service” makes my head explode. I think somehow I should be building a list of security spammers as a “Wall of Shame” to help out the people who would actually buy from these vendors. If anything, I’ll know who not to buy from–the list is getting large enough so that I need to write it down to keep track of.

 

Dear Rybolov,

The need for automated Security Review processes had already made developments in risk tracking one of the areas of greatest interest (and concern) to CIOs, CSOs, and Security Managers worldwide. Now, with the news of Google’s acquisition of Postini, many enterprise organizations are looking even more closely at risk management and compliance as a service.

Many companies lack a repeatable, automated security risk assessment process, and <redacted> would like to offer you a case study that provides an overview of how a leading global financial service provider was able to take advantage of compliance as a service to address risk management and compliance issues while improving business performance.

The specialists at <redacted> are pleased to offer you this case study in an effort to reduce the background noise surrounding this issue and help you focus on the aspects of the process that matter most.

To download this case study at no cost and with no obligation, simply visit: <redacted>

• On Why I Blog… FUD is the Reason for the Writin’
• Database Activity Monitoring for the Government
• More Vendor Craziness
• The Vendors are Already Jumping on the 07-11 Bandwagon
• Ack! With the Mandates!