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).
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.
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.
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 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.
2 comments:
Hi Chris
I wrote my particular way to do this back in December, check it out here. It's very much along the lines of what you're advocating.
Appears to violent agreement.
Post a Comment