New FISCAM

GAO released a draft of a new FISCAM. From the cursory look I have taken, it is a guide for the GAO auditor. Another thing is that they took the time to cross reference to the 800-53. But as I said, I have only taken a cursory review.

http://www.gao.gov/new.items/d081029g.pdf?source=ra

Hopefully, I will get to it within the next week. No guarantees, have a good weekend.

Just buy this and you're Compliant!

Does this really work on anyone?

http://www.wwpi.com/index.php?option=com_content&task=view&id=4839&Itemid=128

To a lesser extent this one:http://www.businesswire.com/portal/site/google/?ndmViewId=news_view&newsId=20080730005428&newsLang=en

Now, I know they aren't coming right out and saying it but it is implied at the very least. The reality is compliance and risk management are hard. Its not what you want to hear. But we will take me as an example: I have an Ubuntu laptop, Windows XP in VMWare), my wife has a MacBook Pro, we have a Windows 2003
server, a Fedora Asterisk PBX/MythTV box and a wireless network.

I spent the last two days attempting to practice what I preach. I have found that even with this small setup it is challenging. Granted, I am running 5 different operating systems. But even if you take away the Mac (which I did, because she wouldn't let me touch it) I still spent a couple hours analyzing myself. The Windows server and virtual machine were quite a distance away from FDCC / SCAP Beta compliance. The SQL server instance on the server and MySQL on the PBX were laughable at best. All in all, without spending too much effort, I would give myself over 100 findings and about 15 - 20 highs, best case (and being creative with combining vulnerabilities).

Here it comes ... my main problem is the operations and management of these systems. No CM, no security analysis before changing things, constantly chasing my tail trying to remember what I did. Poorly documented accounts, inconsistent security policy, no backups, little regard for how equipment is acquired, no regularly scheduled vulnerability assessments or pen tests, the list goes on.

So, what do the "products" suggest I do? Fix ten of my technical problems that I found with a simple VBScript and MBSA. And now I'm compliant. I think not.

Compliance is not easy, it comes from detailed policy and procedures, creating and executing a plan, assessing the residual risks and managing those risks. No product is going to give you that. Can they help you, sure. But they aren't the silver bullet to compliance.

Cloud Compliance

Have a look at this:

http://www.compliance11.com/compliance-management-software.php

A software as a service provider that does compliance. While I can see why someone would want to outsource this type of thing, I am not sure that person would be in or around the Feds.

You know why: a) why would you want to put your compliance data outside your infrastructure; b) you don't know what the backend looks like or who has access and; c) you don't know when the features you like are going away or new ones that you may or may not like are coming in.

I know that it is not directly related to FISMA, but how far away are we for something like this? I talk to some people and they are scared of SaaS or SOA or whatever you call it. They are even more scared that OMB wants more of the government onboard with SaaS for fiscal reasons.

The oppurtunity would be to setup a government wide thing that OMB ran, that would be something. But not just reporting to OMB, I mean requirements management, performing assessments, common ST&E procedures for popular platforms and certification package configuration management.

Perhaps there is something like this already or is on the way. I don't know. But it would be cool, at least for me.

The part where my dreams come true

Today was not expected to be extraordinary. A day trip to New York yesterday, a little sleeping in today, and then I was provided with this gem. M08-21

On the surface it is really nothing; the same memo that comes out every year that tells the agencies how they need to do their FISMA reporting. I then came to page 13 (13 by page numbers, page 16 by adobe).

Question 35: Must Government contractors abide by FISMA requirements?

The short answer: yes. Which is what I said previously. You be the judge though.

My read is that if you process, store or use privileged Federal information then you must certify the system. This means everything. You can't hide behind "its too hard" or "its in the cloud" or my personal favorite "its our equipment".

It does also say that you can share certification packages for agencies using the same system. What a novel idea! An idea I had two years ago. I have witnesses.

I would say this, if you intend to work with the Federal government, certify your systems or at be least prepared. What does this mean? I will give you a plan.

• Review your corporate policies - Are they up to date? Are they crap? Probably. Recommend changes, gain input from people who need to use it. Get buy-in from people who matter.
  
• Compare and trace your policies and procedures to 800-53 and relevant guidance - Match your proprietary policies to the 800-53. Does the 800-53 have controls that your policies don't address? Do your procedures contradict Federal guidelines? i.e. Your desktop configurations or images are not even close to the FDCC settings, event logs settings don't line up to 800-92 recommendations, etc.
• Roll changes - Now you know where you are and with input where you will be going. Break up control implementation into short term and long term goals (upgrade tape libraries, schedule incident response and contingency drills, annual refresher training buying some of those crazy posters of reminding people they should be secure, etc).
  

Now what? By this point, you have started writing a comment that tells me I am crazy. I am. But I am not wrong either. Now you can launch into creating a generic Certification package for your system that is based on your corporate policy. At this point, you can't know which agencies your sales guy is going to bring back. But at least know what you have and the package you create is the one that your organization can live with.

Now you have to start acting like you are running Federal data. Sticking to the SSP, conducting risk assessments, following your configuration management plan, etc. Because the govies can now show up, look you over, maybe conduct their own audit and sign off on your package.

They may not like what your package says, they always find something. You will need to convince the Authorizing Official to accept some findings. The hope is that these are simple policy and procedures deviations between yours and theirs. You may find a hard ass that wants to document a finding when your policy is stronger than theirs. It happens.

But at least it is one package, not three with a bunch of inconsistencies. And then having to run three different incident response drills for three customers at three different times during the year. Or three different training courses all tailored to different policies.

Your system is probably FISMA-ready and you are most likely a lot closer than you think. Because this is what FISMA is all about. Knowing your system, managing your risks, communicating with the government, operating the system as securely as possible.

Remember that the system is what is being certified, not the customer.

FISMA Phase 2

This guy got me thinking on this Phase 2 idea:

http://www.gcn.com/online/vol1_no1/46609-1.html?page=1

The certifiers are supposed to be getting certified themselves. But really, what is the point. With SCAP and FDCC coming down, and no one really giving a shit about there management and operational controls (my experience, yours may be different), why bother.

Stay with me here. Everything is going to be canned, OMB is going to want things in XML or in a specific template. The policies (FDCC and more to come) are going to be government wide. The documentation in a template (ok that's good) and interviews that reveal no detail. Physical security walkthrough, I'll inherit that one.

This program to accredit the certifiers = good idea. Execution = not so much.

Now for some prognostication:

• Who is making sure that the accrediters are certifying properly? NIST? OMB? Individual IGs? This is unclear.
  
• Implementing a FIPS or OMB memo requiring the use of Certified Certifiers. Unlikely. But in case they do, how many are there going to be?
  
• Is the certification by company or by person? If they have a CAP or CISA certification will they be grandfathered?
  
• What kind of reporting will be required of the certifiers to the government to be on the hook for their methods?
• How many are there going to be?

With such a small market of people even offering this type of service, to throw in this extra complexity is ... admirable. From a supply side this is good. Everything is canned, all you have to do is run through the course and then you are firm fixed pricing it all the way to the bank.

But really, how does this help the government manage its risk better? I don't think it does.

I would like to hear some creative ways that the certifiers could be trained / certified to perform these audit functions. But in such a way that is fair to the government AND the auditor. Or to continue this idea that maybe it isn't necessary at all, and that there should be more policy and leadership from the top.