Post #9678291 on why people don’t understand what FISMA really is:  Secure64 DNSSEC Press Releases.

“FISMA Act encourages U.S. government agencies to configure their DNS servers to the DNSSEC security specifications set by the National Institute of Standards and Technology, and it has been reported that the federal government’s Office of Management and Budget (OMB) plans to begin enforcing DNSSEC requirements through an auditing process, setting the standard for DNS best practices.”

Yep, if you stamp FISMA on it, people will buy it, maybe in your PR department’s wettest and wildest dreams.  Guys, it’s been 6 years, that kind of marketing doesn’t work nowadays, mostly because we spent ourselves into oblivion buying junkware similar to yours and now we’re all jaded.

Now don’t get me wrong, DNSSEC is a good thing, especially this month.  But there is something I need to address:  FISMA requires good security management with a dozen or so key indicators, not a solution down to the technical level.  Allusions to OMB are just FUD, FUD, and more FUD because unless it’s in a memo to agency heads, it’s all posturing–something everybody in this town knows how to do very well.  OMB would rather stay out of mandating DNSSEC and maybe give a “due date” once NIST has a final standard.

My one word of wisdom for today:  anybody who tries to sell a product and uses FISMA as the “compelling event” has no clue what they’re talking about.

• Some Words From a FAR
• When the News Breaks, We Fix it…
• Comments on SCAP 2008
• GAO’s 5 Steps to “Fix” FISMA
• How to Not Let FISMA Become a Paperwork Exercise

Potomac Forum is having a 2-day C&A seminar on August 6th and 7th.  It will be unusually good this time because I won’t be there to drag everybody down–I’ll be on the road for some training.  =)  Anyway, check it out and say hi to my instructors from me.

• C&A Seminar, October 15th and 16th
• Certification and Accreditation Seminar, March 30th and 31st
• Another 2-Day C&A Seminar
• How I Spent Friday
• Building A Modern Security Policy For Social Media and Government

Hot on the heels of Security Assessments as Fraud, Waste, and Abuse comes this heartwarming lolcat.

• The Authorizing Official and the Lolcat
• Look Out, Sir Bruce, IKANHAZFIZMA is Coming for You
• Snowmageddon Meets the IKANHAZFIZMA Lolcats
• Happy New Year
• IKANHAZFIZMA Finds Caution Tape

I’m going to put on my Government Security Heretic Hat for awhile here, bear me out.  By my estimate, half of the security assessments received by the Government have some kind of fraud, waste, and abuse.

What makes me say this is the amount of redundancy in some testing that I’ve seen without any value added.

The way to avoid this redundancy is the concept of common/shared controls.  The whole idea is that you take whatever security controls you have across the board and put them into one bucket.  You test that bucket once and then whenever something  shares controls with that bucket, you look at the shared control bucket and make sure that the assessment is still relevant and accurate.

So, what makes a security assessment not fraud, waste, and abuse?  It’s a good assessment if it does the following:

• Does not repeat a previous assessment.
• Discovers previously-undiscovered vulnerabilities, weaknesses, or findings.
• Has findings that get fed into a risk management plan (accepted, avoided, transferred, etc–think POA&M).
• Is not exhaustive when it doesn’t need to be.
• Provides value to the project team, system owner, and Authorizing Official to make key decisions.

Now the problem is that the typical auditor has a hard time stopping–they have an ethical obligation to investigate anything that their “professional skepticism” tells them is out of place, just like cops have an ethical obligation to investigate anything that they think is a crime.

The Solution?  Don’t use auditors! The public accounting model that we adopted for information security does not scale the way that we need it to for ST&E, and we need to understand this in order to fix security in the Government.

What we need to be doing is Security Test and Evaluation which is focused on risk, not on compliance using a checklist of control objectives.  Usually if you know enough to say “Wow, your patch management process is whacked, you’re at a high risk!” then that’s enough to stop testing patch management controls.  This is one of the beefs I have with 800-53A in the hands of less-than-clueful people:  they will test until exhaustion.

There isn’t a whole lot of difference between ST&E and an audit, just the purpose.  Audits are by nature confrontational because you’re trying to prove that fraud, waste, and abuse hasn’t occured.  ST&E is helping the project team find things that they haven’t thought of before and eventually get the large problems funded and fixed.

The Little Frauds Harrigan & Hart’s Songs & Sketches Photo by Boston Public Library

• How to Not Let FISMA Become a Paperwork Exercise
• Cloud Computing and the Government
• Some Thoughts on POA&M Abuse
• 20 Critical Security Controls: Control-by-Control
• An Open Letter to NIST About SP 800-30

The Abbot at the Security Monastery takes us through an interesting tour of compliance, risk management, and what the Government is doing.  I’m not biased at all because it’s based on conversations with me or anything like that.  =)

Now for those of you who don’t know me personally, here’s a little bit of trivia for you:  Every week I go back and forth between “wow, we’re doing great things above and beyond what the private sector knows about” and “culturally, security in the Government will never work because you’re trying to do risk management in a zero-defects world”.

• An Open Letter to NIST About SP 800-30
• New SP 800-60 is Out, Categorize Yerselves Mo Better
• It’s a Problem of Scale!
• NIST’S FISMA Pase II–Who Certifies Those who Certify the Certifiers?
• Some Comments on SP 800-39

The perpetual draft document, SP 800-53A, has been officially released after 3 years.  Check out the announcement from NIST here.

Now the interesting thing to me is that NIST is working with some other players (DNI comes to mind) on reference implementations of 800-53A.  This is big, so big that I can’t add enough hyperbole to it.

Why do they need to do reference implementations?  Well, because by itself, SP 800-53A is dangerous if it’s given to people who “don’t get it”.  By that what I mean is this:

• SP 800-53 needs tailoring to distill into actual requirements.
• SP 800-53A needs a huge amount of tailoring to distill into test cases/procedures that match the tailoring that you did with 800-53.
• Taken at face value, 800-53 and 800-53A become the source of “death by compliance”.
• If you think the auditors could grill you to death with 800-53, 800-53A gives them tons more material.

Now time for a war story: I worked on a project where the contractor was having a hard time building a security program, mostly because they didn’t have the right staff to get the job done.  The government told the contractor to use 800-53A as a starting point, and 6 months of insanity followed with 13 “security engineers” in a conference room cranking out documentation that had no basis in reality.  At the end of it all, the contractor handed the Government a bill for $1M.

Now don’t get me wrong, I like the ideas behind 800-53A, but the first thing you need to know when you start using it is when you shouldn’t use it:

• Don’t run test procedures on every computer you have, use an automated tool and do spot-checks to validate that the automated tool works.
• Use less test procedures on low-criticality systems.
• “This procedure is conducted as part of the hardening validation process.”
• Common controls are even more important because you do not want the repetition of effort.

And whatever you do, don’t let 800-53A turn your risk management into a compliance activity.  It has all the potential to do that.

US Government Doc’s photo by Manchester Library.

• OMB Wants a Direct Report
• An Open Letter to NIST About SP 800-30
• Auditors, Frameworks, and Philosophy
• Security Assessments as Fraud, Waste, and Abuse
• Observations on SP 800-37R1