NASA's FISMA stance stirs up a debate
Readers still see value in certification and accreditation process
- By Government IT Community
- Jun 11, 2010
NASA’s top cybersecurity official raised a few eyebrows and won a lot of fans last month when he said the cost of complying with the Federal Information Security Management Act was not a good investment.
Rather than spend tens of millions of dollars going through the paperwork-intensive certification and accreditation process in 2010, NASA planned to invest its money in technology that would make it possible to manage security risks in real time, said Jerry Davis, NASA’s deputy chief information officer for information technology security.
“Security is still going to be done,” he told Federal Computer Week’s Ben Bain. "Certification and accreditation will still be done, but the way we do it is going to change significantly and the frequency of it will change. Instead of every three years, you’re really going to be doing it, in a sense, on a weekly or monthly basis. You’re always going to be looking at those controls and adjusting them for changes."
Many cybersecurity experts cheered Davis, suggesting that he spoke aloud what a lot of government officials have been thinking for some time. But numerous FCW readers see it as a dangerous precedent that ignores the real value of the certification and accreditation process. Here is a sampling of the comments we received.
[Editor's note: Comments have been edited for length, clarity and style].
Watch the Watchdogs
I would really like to know what the NASA inspector general has to say, because until the FISMA law changes, federal agencies are required to follow current policy. Many agencies have tried to implement many risk-based, cost-saving measures. But if you are an organization that is audited by your IG and the Government Accountability Office, you will find that this type of action meets with many issues in the way of adverse findings.
Not Soon Enough
The really sad story is that this decision was not made about a year ago before the next round of paperwork started. Then NASA could have had some real significant savings. Since we are stopping this late into the process, we have wasted a lot of resources. At least as part of the processes, we have updated our risk assessments and our plans of actions and milestones. The best news is that NASA's horrific IT security documentation generator/repository looks like it will be rocketed out of NASA's cyberspace.
— A NASA information system security officer
Show Your Work
Has Mr. Davis produced a business impact analysis that he would be willing to share publicly or in redacted form? Wouldn't someone do that before issuing a blanket policy memo directing change with considerable risk implications?
Truth and Consequences
Maybe the IG of NASA needs to have another look at the memo and document the risk to NASA and any agencies using NASA services. No one is arguing with a fresh look at FISMA and even tossing it out in favor of something better. What really is frustrating is the Senior Executive Service mentality of super-solution and super-memo with no regard to what actually needs to be done and how and by who and when…. Where is real governance with real consequences?
Not Measuring Up
The question is: What good is the technical monitoring if you don't know what you’re looking at, other than a workstation or a server? Also, without the requirement of a certification, all people will do is ensure their machine can be patched or be off the network and nothing more. What is measured is done, and since NASA will now measure patching, this is what will get done.
— Daniel Philpott
A Poor Posture
A security monitoring tool is not going to tell you your complete security posture. At best, the tools are a passive approach to managing vulnerabilities detected in the information systems. What if you fail to train your employees, and someone downloads an e-mail message with a virus? Your tool will detect the virus, but it won't detect the yahoo downloading the e-mail. Root cause, folks. Start integrating the risk management framework into your software development life cycle process. That is your first step to implementing a successful security authorization process.