More Annoyance

Back again.

Yesterday, I said that the recent survey about FISMA failure is horse shit. I stand by that claim and will now add more.

The only thing this report says is that their process is too focused on compliance and they wish they had more money. When is the last time that you talked to someone where they didn't wish they had more money for their program? Whatever the program was. "I wish I had more money for building my space station" or "If I had another $2 million dollars, I could get something with red blinking lights instead of blue blinking lights."

This survey has had it's effect, we're talking about FISMA. The failure does not lie in the law though. I see and hear about the failures every day. Management buy-in is lacking, risks ignored, security bolt-ones at the end of the project, or security isn't keeping up with technology. I think that just about everyone in this industry could say all the same things. And they don't have a law to tell them they have to do it. A lot of organizations have no prevailing regulatory requirement to follow and those security folks have to get more done with much less than the government provides to a lot of agencies.

One of the slides said that nation-states were attacking the government systems all the time. Whatever, everyone is getting attacked by nation-states.

A different slide said that users were their problem and they didn't have enough training budget. To this, I refer you back two paragraphs where virtually every CISO/ISSO complains about this.

I said on the Southern Fried Security podcast FISMA episode that FISMA improved Federal government security. Anyone that can prove other wise please step forward. Because when FISMA was passed many agencies were lucky to have a firewall and anti-virus. Let alone web application firewalls, intrusion detection systems and pen tests. No one was training users on security awareness on a regular basis (not for the places I was working for anyway).

In the end, FISMA leaves the implementation of policy to the agencies. That policy should be based on 800-53. If you need help, I am here for you.

That is all.

Posted with Blogsy

800-53 Appendix J - Privacy Controls

I feel like I need to say something about the latest addition to my favorite document.

Redundant and unnecessary springs to mind. While new words may be used to talk about the same things, the bottom line is the same as it always is: limit what you collect and then protect it with in the budget constraints you have.

Below is the text of an email I have sent to a number of my customers (as they pay my opinion on such things).

Subject: NIST 800-53 Rev 4

NIST is projecting a release of an updated 800-53 in December. At this time, the only thing that is changing is the addition of Appendix J. Appendix J provide 23 new controls related privacy data protection.

After a quick review, I do not believe that we are in any danger of having to implement something new as far as technology. However, we may need to go through the exercise of updating our documentation to add these new controls (should decide to adopt them).

Attached is the draft of Appendix J for your review. Let me know if you have any questions.

-C

Of course, I attached the PDF for them - you can look at here: http://csrc.nist.gov/publications/drafts/800-53-Appdendix-J/IPDraft_800-53-privacy-appendix-J.pdf

I know that some organizations feel they need these new controls. The ones I work with are not those. If I am totally cynical about the whole thing; I think that this is a way for some people to check more boxes to say how awesome they are OR for someone to justify spending more money on technology that should already be in place.

On Greed and Complianciness

Disclaimer: This post is not inspired by any past or present events in my work or personal life. The opinions expressed here are mine and not necessarily those of any of my employers, customers, vendors or organizations with which I affiliate.

As the Gulf coast becomes another environmental disaster and still recovering from the financial meltdown, I can't help but think about the parallels between having a well run information security program and compliance. You must know by now, I am an advocate of the work NIST has done as a result of FISMA. This has led to the many 800-series documents which helped many organizations, despite what the haters may say. We need compliance and compliance frameworks, if we don't then nothing will happen.

BP was not required to have the secondary piece of equipment, so they didn't put it in. Now look what happened. Wall Street gambles with people's mortgages and livelihoods, and the taxpayers (in the form of the Federal Reserve and Bailouts) have financed the losses.

In the same vein, why would an agency or department spend taxpayer money on security when they aren't required to? Especially since there is a deficit and a push to contain costs. They wouldn't. Congress had to mandate it.

I'm not trying to make a political statement, I am saying that without compliance programs and frameworks - a company would do nothing. Without the threat of fines from compliance or public relations disasters, a corporation has no incentive to do ... anything.

So here again, let us not confuse failures because a company practices complianciness. We should also not be surprised that an organization chooses to take the path of least resistance and doesn't put resources towards a real information protection program.

Missing the Point ... Again.

There has been a lot of who-ha (technical term) going around on the changes to Information Security in the Federal government. As the title suggests, there are many, many pundits and "experts" who proclaimed FISMA as a failure and needs an overhaul. It is my opinion that very little will actually change. Why you ask?

Institutional Momentum.

Like most things in the government, the original idea came from DoD and the Intel community. In this way, Certification and Accreditation could be a point in time event because they were running mainframes with hard wired terminals. So things did not change all that often. Systems evolved, web applications were developed, cloud computing, buzz word du jour, blah blah and suddenly the process is broken.

Did you know that certification is only mentioned once in FISMA? And not even the certification that we think of, it concerns a certification authority for digital signatures. Congress did not force the Certification and Accreditation process onto the Executive. If we jump into our way-back machine you may recall a post where I said that FISMA is about risk management. Continuous monitoring and vulnerability management were part of this vernacular from the start. FISMA was perverted into a checklist / table top exercise to keep costs and schedule under control, which is totally permissible if you accept the risk. Some of the feds simply were not ready to implement the NIST recommendations. Some still are not.

You may also know that a few weeks back, SP 800-37 Rev 1 went final. It seems that it has taken just over seven years, but the government produced meaningful recommendations to create a process to manage risk. With this document and the upcoming SP 800-39, we finally move in the direction of strategic risk management. While I have only taken a cursory look at the bills on the Hill, my understanding that there is little in the way of increasing the government’s ability to respond to incidents, perform practical contingency and business continuity exercises or enforce more extensive testing methodologies. I believe this has to do with vendor influences, but I could be completely wrong in my assumptions.

FISMA has done exactly what it was intended to do. Those who didn't/don't/can't understand security, vilified it from the start. Which I felt was an attempt at a self fulfilling prophecy. Lest we forget where we were in 2002. Very little was done beyond a firewall on the perimeter and some A/V on the desktops. Because of FISMA and the thousands (perhaps millions) of findings written, many more technologies have been deployed such as web application testing and intrusion detection. We all understand that we can and should do more, but that is all security programs. This one just happens to be open to regular public criticism. Outside critics should consider the 800 series documents for what they are, guidance for the creation of a solid security program and not as simply a compliance effort.

It would have been better if the new legislation simply said "Do what we already told you to do, but ‘this time with four part harmony and feeling’". Ending with funding for agency staff education and time off to go learn what information system risk management really is.

Disturbing Trend

I don't mean to be an alarmist or whatever. But that's how newspapers get sold and stations get ratings. What is this mystical issue? The answer is Control Implementation Prioritization.

Way back in February 2009 we were greeted with the Consensus Audit Guidelines (CAG). I personally do not care for CAG. Some people will get their controls implemented faster, better, cheaper. At a minimum, the guidelines are misleading since it had little to do with actual auditing or system security testing.

At the beginning of May, they revised CAG into 20 Critical Security Controls (CSC). Well at least now, there is some truth in the title. They are sold to us as controls that every system should implement. Well ... thanks. Let's take a quick look then.

Ahhh. Ok. So where is the part about laying down a strategy or developing an initial policy that needs to be followed. Its not there. Where is the part about strength and cost of the control implementation as measured against the risk. I couldn't find that either.

Apparently, that doesn't matter anymore. It is clear from the beginning that the focus of CSC is not about system-specific risk analysis anymore. So that is that, but then in Appendix D of the 800-53 Rev 3, Final Public Draft. What do my eyes find, CONTROL PRIORITIZATION. On a scale of 1 to 3 and a 0 for unspecified.

Now for the meat - why is this bad. Its bad because management types will focus on the number 1. "I have to do these controls first, because NIST told me so". Or "I have money for the top 20 then I will deal with the rest".

It has been proven time and time again security comes from determining risk and implementing controls comensurate with that risk. Then reassessing that risk and control effectiveness over time using adequate metrics. Plan for the worst with contingency and incident handling plans. Et cetera.

Implementation of the CSC will not make you safer, it will make the vendor richer. A total soup-to-nuts program is still the only way from my opinion. This would include selecting controls that you deem necessary.

The CAG

Otherwise known as the Consensus Audit Guidelines.

In summary: Do everything we've been telling you to do. Identify -> Assess -> Secure -> Monitor -> Repeat.

See I just saved you two hours of reading.

But seriously, I suppose my main objection (from a very cursory review) is that now the technical controls that have generally been assessed using automated tools, will now be weighted more heavily than those which could conceivably be just as important.

Which is why we have (drum roll please ...) Risk Assessments. So that intelligent humans can decide for themselves which controls are more important than others in their environment.

Taking a step back, FIPS 199 (pdf) asks you to look to the 800-60. In the 800-60 (pdf), there is a lot of discussion around deciding what type of data you are processing, how sensitive is it, whose allowed to see it, who is isn't, etc. From that you are supposed to be able to extract a mystical level of concern for your data (Low, Moderate and High). In my career, I have only personally ever seen one (1) High system and that was for availability. The rest if you must know were/are Moderates.

As the auditor for the High system, we heavily weighted the Incident Response and Contingency Planning controls. We even had the authorizing authority and certification authority say they didn't want to *really* impose the High controls for most of the Technical family (gasp!). We call this a risk based decision. The risks for them were purely from a "keep the damn thing up for the love of all that is holy and good" perspective. But this isn't what I wanted to talk about, I think...

These boiled down "critical controls" are a dangerous thing, in my opinion. Anyone who has been put in a capacity to use/implement the guidelines, I imagine is having similar reactions. Because (again!) there is nothing new here. Now with more confusion because they are guidelines, like all the 800-series documents are guidelines.

Perhaps I will do a more detailed analysis and comment. For now, I find myself agitated and tired.

And they used the word "cyber" too much, MS-Word and OpenOffice don't even think it is a word.

GAO: FinCEN InfoSec Program = Bad

Like most bad news Washington, this GAO report was released on a Friday afternoon. This Friday afternoon happens to be before the Super Bowl of all things. So this is a special Friday where it almost certain to be overshadowed by the drama of the “Big Game”.

This report (that I got to read, believe or not) tells the story of the security posture of the Financial Crimes Enforcement Network (FinCEN). FinCEN is responsible for some important things not the least of which is keeping money laundering to a minimum, stopping terrorist financing and investigating other financial crimes. You may be interested to know that it has ties to many financial institutions, casinos and other places where big money may be. This is also the group that banks notify when you move $10,000 or more.

Ok, so now you know who they are and what they do. Here's the rub:

Although FinCEN, TCS, and IRS have taken important steps in implementing numerous controls to protect the information and systems that support FinCEN’s mission, significant weaknesses existed that impaired their ability to ensure the confidentiality, integrity, and availability of these information and systems. The organizations have implemented many security controls to protect the information and systems. For example, FinCEN employed controls to segregate areas of its network and restrict access to sensitive areas, and IRS controlled changes to a key application in its BSA processing environment. However, weaknesses existed that placed sensitive data at risk of unauthorized disclosure. The organizations did not always consistently apply or fully implement controls to prevent, limit, or detect unauthorized access to devices or systems. For example, the organizations had not consistently or fully (1) implemented user and password management controls for properly identifying and authenticating users, (2) restricted user access to data to permit only the access needed to perform job functions, (3) encrypted data, (4) protected external and internal boundaries, and (5) logged user activity on key systems. Shortcomings also existed in managing system configurations, patching systems, and planning for service continuity. As a result, increased risk exists that unauthorized individuals could read, copy, delete, add, and modify data and disrupt service on systems supporting FinCEN’s mission.

Holy F@%!, Batman!

I would say this is in the category of jobs that you don't want to have. Or at least had. One thing that I think I can infer from the report, is that the system is not classified. Meaning people didn't have clearances to work on the system. But there doesn't appear to be any discussion about that and I am not saying that it needs to be. On this point, I want to say that there is enough documentation and business processes out there to support doing this better.

Now, I am not going to keep writing and lamenting that our data isn't safe. This is a tough job and usually information security is something that gets tacked on. The ST&E portions of the Certifications on the system were probably rushed and people missed things. Some things get rushed out the door, some risks get accepted, whatever.

But seriously, there are some pretty basic things that the Continuous Monitoring efforts should have taken care of: excessive user rights, unused accounts, limited or missing encryption. Read the report for yourself it reads like How not to do Information Security. And now for the moral of the story.

The answers here and with most organizations will not lie with new technology but with leadership, a plan and processes. Some of it, like the mainframe, sounds like it needs an upgrade. The common thing though are operational keeping an eye on user accounts, monitoring the logs, IDS; those are things that need humans with eyes and analytical skills.

Scan, Baby, Scan!

I recently experienced death by scanning (maybe death is too strong, extreme pain). The system I am supporting is eventually used by the government which means FISMA and by extension certification agents. I still do some certification agent work and I will say that it is still a foggy area. Some will take it to the Nth degree and dig in to every facet and crevice to get the best assurance possible. Others will do a superficial scan and call it a day.

My current annoyance in the ability to ascertain the security posture is this; the management of the little system wants as few vulnerabilities as possible, obviously. So naturally, their scanning policy is tailored to the system and to the excepted risks. The certification agent has their own process for assessment, good for them. However, their process does not include updating their process for the environment.

The two processes are at odds with one another, so we are constantly chasing vulnerabilities. Different tool sets, different time lines, different policy baselines, plugin updates, the list goes on. When I try to convince that less scanning needs to happen, we in fact get more.

Most people I talk to would agree, it would be good to run as many tools as possible at your environment. I am currently frustrated by it.

There really wasn't any point to this story except that scanning with 19,000 tools is helpful as long as everyone is on the same page and can adequately communicate that page. So far, I have apparently been an ineffective communicator or my communication has been accepted and then moved aside in an effort to portray a rosier picture.

A new plan will have to take shape now. Details to follow.

Loss Prevention is not Risk Management

I have been giving a lot of thought about how to deal with Risk Management recently. I have talked to a few people and I have come to realize the title of this post. Many of my colleagues only talk about making sure the data doesn't get released, corrupted or unreachable. In my own little head, this to me is loss prevention. Retailers do it all the time, they put those annoying tags on the clothes so that you can try them on properly, to make sure that they don't experience a loss. I'm not saying that the RM and LP are not related, they are. But a loss prevention is the
implementation of controls is not a risk management. I am define risk management as (like Wikipedia):

a structured approach to managing uncertainty related to a threat, a sequence of human activities including: risk assessment, strategies development to manage it, and mitigation of risk using managerial resources.

Most of the time, I have started the risk assessment process with a threat identification, where we list out all the threats. The question is "Do we care?" The answer of course is "No". Stick with me now. Has the person in charge ever turned to you in the beginning of the incident
response ever turned to you and said "I have the Risk Assessment here can you tell me which threat succeeded and which control failed?" Maybe a few but not many, the question that they asked me was, "What failed and (delicately) how do we get the shit back in the horse?" Results not causes. In the heat of the moment, I haven't met anyone that said "I spent three days with a
CVSS calculator determining that the threat is a 2, xxxxxxx turned into a ... ."

You know the next steps, list of threats paired to vulnerabilities, and if you are using the 800-30 then you do the arbitrary but necessary likelihood and impact. To come up with a risk. And there was much rejoicing. Yea! I have checked the proverbial box, submitted my POA&M and now I will retire to the veranda for coffee without a care in the world, right? Wrong.

My perception is that we are working this thing backwards, at least in the Federal government space (which is all I am really familiar with). With the Feds, we know the controls we are going to implement (800-53 or CNSS 1253). And then we know what we don't want to happen, you know ... bad stuff that gets us in the Washington Post or dragged up the Hill.

So let me lay this out, the threats are changing, there are always new vulnerabilities (the only constant is change ), the likelihoods and impacts are subjective so why should we expect anything from that process. Or at best, something we can take action upon.

I have watched many smart people stand up new firewalls, IDPS, NAC solutions, SOCs, AV, whatever and still in the end something gets missed or the human element gets in the way. Because simply implementing and monitoring controls without the understanding of the risks those controls are protecting against is not good. It is just doing Loss Prevention.

Put down the DCID 6/3 and walk slowly towards me

While this does not personally excite me since I don't live in an IC or DoD world, the ODNI has abandoned DCID 6/3 in favor of the new CNSS instructions. It is only about a year late, since the first time I heard this was happening was in 2006 with an implementation of 2007. The news release is here: http://www.dni.gov/press_releases/20080930_release.pdf

The directive is here: http://www.dni.gov/electronic_reading_room/ICD_503.pdf

And I found out about it from here: http://infosecurity.us/?p=1918

Thanks Mark!

The Amtrak Post

Hello from a stopped Amtrak train near Aberdeen, MD.

I just wanted to spend a few minutes to let you know that the SCAP Conference was almost a total bust. This would be mainly due to no new information. At least last year, I left the conference with the hope that things would change through a new 800-37 or the final release of the 800-53A.

This year was mainly about scanning. For someone who has done more than a couple scans, it was painful. Dr. Ron put on his usual show about the future and how great things will be eventually. Other speakers lacked public speaking ability which took away from their content. Don't even get me started on the grammar errors in the presentations or the blatant "I am great. Look at what I can do, but you f%#!ers are screwed".

If you were a vendor, then this was probably a dream for you. Captive audience with a narrow focus. If you could spell SCAP, then you were set. But I am not here to ding the vendors, that's just how capitalism works. There were a few good sessions on how SCAP works, which some of those vendors found to be news. While empowering the attendants to understand what to look for when choosing a product.

CSAM is now a web based product which I somehow missed. I didn't get to see it but my new friend Shawn likes it.

They seem to be very proud of themselves for getting the IC and DoD on board with some of the 800 series. I suppose that is good, but I got tired of hearing about it after the 16th time.

I would have preferred to have seen more discussion around turning assessment results into meaningful risk management processes. But alas (as the Rolling Stones said), you can't always get what you want.

Alive Check

This is to let you know that I am alive.

Real quickly - I am putting my 800-37 comments and working my pet project.

800-37 Draft Out

How exciting:

800-37 Initial Public Draft (via Guerilla-CISO)

Comments to follow.

More Commentary from the Unknowing

I am not certain what the point of this article started out as:

http://www.scmagazineus.com/Is-FISMA-fizzling/article/113025/

But I am fairly certain that someone said, "Go write something about FISMA." For me, it is additional aggravation. Why? Let me tell you.

They ask the same people the same questions every time expecting a different result. Albert Einstein said it best.

FISMA is a paperwork drill at a minimum, when properly applied it can actually benefit the organization. Like most things you reap what you sow. If you believe it is a paperwork drill, then that is what you get. If you believe that value can be driven by:

• requiring a set of controls be implemented;
• testing against that set of controls;
• identifying risks based on a control's lack of implementation;
• strengthen the controls now that you know the risks;
  
• tracking residual risks throughout the life cycle of the system.
  

Then, you perhaps may see some return.

My opinion is that those who think that a paperwork drill is sufficient should consider changing their tune, because it won't be long before someone expects a real risk management.

Think 800-60 is to FIPS 199 and 800-53 is to FIPS 200 as 800-39 is to ...?

The Federal Information Infrastructure Response Enhancement Act

Apparently, when it rains it pours. I picked up this link this evening:

http://www.nextgov.com/nextgov/ng_20080801_2626.php

I suppose what scared me the most when I read this little article is this line:

"Members of the federal information security community have been involved in shaping the bill..."

Which means vendors. I also think the CISO council that they want formed will need defined intervals and smaller working groups inside that structure.

Lastly, this idea of DHS running a red team. Why not fund each IG with the ability to do real audits? Or the GAO? Then there isn't going to be any of this, "DHS isn't going to look at my stuff". Because I agree that the red team would have to be so big that managing it would be close to impossible

We'll see though. My final thought based on what little information I have here is ... let's treat the problem not the symptoms. What I mean is why can't they legislate a better risk management, rather than running some more scans.

You know why ... vendors sell scanning tools, not solid risk management processes and procedures. I'm just saying.

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.

Start Your Security Assessments!

It is here. The 800-53A is now official.

I haven't looked it over yet, but I thought I would throw it out there.

FISMA is about Risk Management

I feel inclined to talk about something that the Guerrilla CISO discussed earlier.

I found this post at ISC2 annoying in that it is the same in a long line of "look at all these problems with FISMA" writings. We get it, its new (relatively, for the government) and there are problems.

But just like all the other posts, no solutions are offered. I don't have all the answers either, but now, I will be more aware of when I am spewing and when I am trying to be helpful.

So, let's go there. The reporting and measurement of system risks is nebulous, at best. Specific training for Accrediting Authorities (AA) and their delegates would be the first thing to do. The topics would look something like:

• Introduction to Risk Management
• What is Risk?
• How do I know my risks?
• How to conduct a Risk Assessment
• What are threats?
• What are vulnerabilities?
• Determining likelihood
• Determining impact
• Generate Risk
• Risk Management (MEAT, I just made up this acronym)
  
• Mitigation (Compensating or additional controls)
• Elimination (Remediate underlying vulnerabilities)
  
• Acceptance (Justification for Operational Necessity)
• Transfer (Delegate up or down, buy insurance)
• Balancing Success and Usability with Security and Assurance
• Or How not to add too many countermeasures and controls to make the system costly to run.
• Measurement and Reporting of Residual Risk
  

I find that second last one to be the general issue and the root of many of breaches. Either the system has no budget so the AA has to except risks they may or may not be comfortable with. Or the system has too much budget and the Security Architect goes overboard. Lastly, not all risks are discovered at the time of accreditation and no new risk assessments are conducted.

So once all that is done, it must be uniformly applied (directly to the forehead, haha). More simply quarterly or semi-annual summits/counsels/conferences with the AAs with case studies, panels and open forums to discuss emerging threats, emerging countermeasures, what risks should be accepted, etc. Keeping it as simple and high level as possible, given that some of the AAs have little to no IT background.

This may already be happening and I am not aware of it. Please let me know if it is or isn't or anything you would want to see as possible solutions. It would be up to NIST or OMB to institute something like this, since FISMA gives them that authority. Or I accept Cash, Check, Wire Transfer, Money Orders and Google Checkout.

FISMA Report Card

I know that I am late on this one, but I have been busy. Just for a brief moment let's consider the point of these report cards and from where they come.

My personal feeling is that the report card means nothing and says even less. They apply an arbitrary metric to an ambiguous reporting mechanism. Any agency could have the best, most secure systems. If they don't report on it correctly, they can still fail. This also means that if the people performing the reporting are not trained correctly they can fail. Lastly, those who know how to report can pass without necessarily having secure systems.

Someone told me recently that the intent of this is to: a) make Congress feel good about doing something productive and b) inspire agency competition for success.

Sorry I am so negative on this, but again there is an "end of project requirements mismatch discovery". OMB, NIST and others recognize that good information systems security comes from well written policy and superior risk management. When others will tell try to sell IDPS, firewalls and log management platforms as solutions to your FISMA problems.

This report card reinforces an over simplified view of how easy/hard it is to secure an enterprise.

A New Draft of the Same Thing with Thoughts on Outsourcing

The 800-123 Guide to General Server Security came out this week, and really who needed this. I am sure this would have been helpful in 1995, when people had just started putting servers on the Internet. But who is seriously going to sit down with this and say "I hadn't thought of that!"

What I think we need now in the age of government *sourcing is some NIST guidance around Cloud, Managed and Virtualized systems.

My personal belief is that vendors are trying to get management/operation of government systems out of the government's hands so that there isn't as much bureaucracy.

Here is the thing, it is still the government's data. The system still must be certified.

To the Honorable Karen Evans: Please issue a memo stating unequivocally that: outsourced, managed, clouded virtualized, SaaS, shared whatevers need controls implemented to the same level that they would be if the government had built it themselves.

Quoteth the FISMA 3544(a)(1):

"(A) providing information security protections commensurate with the risk and magnitude of the harm resulting from unauthorized access, use, disclosure, disruption, modification, or destruction of—
"(i) information collected or maintained by or on behalf of the agency; and
"(ii) information systems used or operated by an agency or by a contractor of an agency or other organization on behalf of an agency;

So for those of you out there who keep saying "Chris, it isn't in the agency's physical boundary". Stop it. You know who you are.

More on this later (I keep saying this, but will it ever happen?).