If you're new here and would like to see more of what I'm saying, you may want to subscribe to my RSS feed or have a look at my papers and presentations page for downloads of stuff that you can share or "borrow heavily from". You also might find my guidelines for posting comments interesting, especially if you're a government employee. Thanks for visiting and happy hacking!

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

Bookmark to:

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.

Bookmark to:

Article from William Jackson in Government Computer News:  Security policies remain a burden to federal IT managers, but they are producing results.

First off, GCN, come into the modern Web 2.0 era by letting people comment on your articles or at least allow trackbacks.  Having said that, let’s look at some of Mr Jackson’s points:

• NIST Special Publications: They’re good.  They’re free.  The only problem is that they’re burying us in them.  And oh yeah, SP 800-53A is finally final.
• Security and Vendors/Contractors:  It’s much harder than you might think.  If there’s interest, I’ll put out some presentations on it in my “copious amounts of free time”.  In the meantime, check out what I’ve said so far about outsourcing.
• Documentation and Paperwork:  Sadly, this is a fact of life for the Government.  The primary problem is the layers of oversight that the system owner and ISSO have.  When you are as heavily audited as the executive branch is, you tend to avoid risks and overdocument.  My personal theory is that the reason is insistence on compliance instead of risk management.
• Revising FISMA:  I’ve said it time and time again, the law is good and doesn’t need to be changed, the execution is the part that needs work.

Bookmark to:

Check out this slideshow and this workshop paper from 2006 on some ideas that NIST and a fairly large advisory panel have put together about certification of C&A service providers.  I’ve heard about this for several years now, and it’s been fairly much on a hiatus since 2006, but it’s starting to get some eartime lately.

The interesting thing to me is the big question of certifying companies v/s individuals.  I think the endgame will involve doing both because you certify companies for methodology and you certify people for skills.

This is the problem with certification and accreditation services as I see it today:

• Security staffing shortage means lower priority:  If you are an agency CISO and have 2 skilled people, where are you going to put them?  Odds are, architecture, engineering, or some other high-payoff activity, meaning that C&A services are candidates for entry-level security staff.
• Centralized v/s project-specific funding:  Some agencies have a “stable” of C&A staff, if it’s done wrong, you end up with standardization and complete compliance but not real risk management.  The opposite of this is where all the C&A activities are done on a per-project basis and huge repetition of effort ensues.  Basic management technique is to blend the 2 approaches.
• Crossover of personnel from “risk-avoidance” cultures:  Taking people from compliance-centric roles such as legal and accounting and putting them into a risk-based culture is a sure recipe for failure, overspending, and frustration.
• Accreditation is somewhat broken:  Not a new concept–teaching business owners about IT security risk is always hard to do, even more so when they have to sign off on the risk.
• C&A services are a commodity market:  I covered this last week.  This is pivotal, remember it for later.
• Misinformation abounds:  Because the NIST Risk Management Framework evolves so rapidly, what’s valid today is not the same that will be valid in 2 years.

So what we’re looking at with this blog post is how would a program to certify the C&A service providers look like.  NIST has 3 viable options:

• Use Existing Certs: Require basic certification levels for role descriptions.  DoD 8570.1M follows this approach.  Individual-level certification would be CAP, CISSP, CG.*, CISA, etc.  The company-level certification would be something like ITIL or CMMI.
• Second-Party Credentialing:  The industry creates a new certification program to satisfy NIST’s need without any input from NIST.  Part of this has already happened with some of the certifications like CAP.
• NIST-Sponsored Certification:  NIST becomes the “owner” of the certification and commissions organizations to test each other.

Now just like DoD 8570.1M, I’m torn on this issue.  On one hand, it means that you’ll get a higher caliber of person performing services because they have to meet some kind of minimum standard.  On the other hand, introducing scarcity means that there will be even less people available to do the job.  But the big problem that I have is that if you introduce higher requirements on commodity services, you’re squeezing the market severely:  costs as a customer go up for basic services, vendors get even less of a margin on services, more charlatans show up because you’ve tipped over into higher-priced boutique services, and mayhem ensues.

Guys, I’m not really a rocket scientist on this, but really after all this effort, it seems to me that the #1 problem that the Government has is a lack of skilled people.  Yes, certifying people is a good thing because it helps weed out the dirtballs with a very rough sieve, but I get the feeling that maybe what we should be doing instead is trying to create more people with the skills we need.  Alas, that’s a future blog post….

However, the last thing that I want to see happen is a meta-game of what’s going on with certifications right now–who certifies those who certify?  I think it’s a vicious cycle of cross-certification that will end up with the entire Government security industry becoming one huge self-licking ice cream cone.  =)

Bookmark to:

Dear NIST People,

I have this semi-random digital scribbling thingie called a blog.  You might have heard of them.  Hey, you might have even at one point heard of mine.  =)

On my blog I let it be known that I am what the rest of the world would call a “NIST Cheerleader”.  I watch your every move.  I comment on your new publications.  I teach your framework every quarter.  From time to time, I criticize, but only because I have a foot in the theory of information security that you live and a foot in the implementation with agencies who know where the theory and models break.

The best thing that you have given us is not the risk management framework, it was SP 800-30, “Risk Management Guide for Information Systems”.  It’s small, to-the-point, and scalable from a single server to an entire IT enterprise.  Sure, the quants hate it, but for the quals and Government, it’s good enough.  I know private-sector organizations that use it.  One of my friends and blog readers/commenters was the guy who taught a group of people how to do risk assessment, then these same people went on to help you write the book.

I heard that you were in the process of revising SP 800-30.  While this is much needed to catch up/modernize, I want to make sure that 800-30 does not follow the “live by the catalog, die by the catalog” path that we seem to be following lately.  In other words, please don’t change risk assessment process to the following:

1. Determine boundary
2. Determine criticality
3. Conduct a gap assessment against a catalog of controls (SP 800-53/800-53A)
4. Attach a priority to mitigation
5. Perform risk avoidance because compliance models are yes/no frameworks
6. Document
7. ???
8. Profit!

At Your Own Risk Photo by  Mykl Roventine.

The reason that I am writing this is to let you know that I have noticed a disturbing trend in how now that we have a catalog of controls, the risk management framework is focusing more and more heavily on the catalog as the vehicle for determine an adequate level of security.  Some of this is good, some of this is not.

Why am I so concerned about this?  Well, inside the Government we have 2 conflicting ideas on information security:  compliance v/s risk management.  While we are fairly decent Government-wide at compliance management, the problem that we have is in risk management because risk management is only as good as the people who perform the risk assessment.  Not that we don’t have competent people, but the unknowns are what will make or break your security program, and the only way that you can known the unknowns is to get multiple assessments aimed at risks outside of the control catalog.

However, if you change the risk assessment process to a “catalog of controls gap analysis” process, then we’ve completely lost risk management in favor of compliance management.  To me, this is a disturbing trend that needs to be stopped.

Thank you for your time

–Rybolov

Bookmark to:

Ever watch a marathon on TV?  There’s the usual formula for how we lay out the day:

• History of the marathon and Pheidippides
• Discussion of the race length and how it was changes so that the Queen could watch the finish
• World records and what our chances are for making one today
• Graphics of the race course showing the key hills and the “sprint to the finish”
• Talk about the womens’ marathon including Joan Benoit and Kathrine Switzer
• Description of energy depletion and “The Wall”
• Stats as the leaders hit the finsh line
• Shots of “back-of-the-pack” runners and the race against yourself

Well, I now present to you the formula for FISMA Report Cards:

• Paragraph about how agencies are failing to secure their data, the report card says so
• History and trending of the report card
• Discussion on changing FISMA
• Quote from Karen Evans
• Quote from Alan Paller about how FISMA is a failure and checklist-driven security
• Wondering when the government will get their act together

Have a read of Dancho’s response to the FISMA Report Card.  Pretty typical writing formula that you’ll see from journalists.  I won’t even comment on the “FISMA compliance” title.  Oh wait, I just did.  =)

Some myths about FISMA in particular that I need to dispell right now:

1. FISMA is a report card:  It’s a law, the grades are just an awareness campaign.  In fact, the whole series of NIST Special Publications are just implementation techniques–they are guidance after all.  Usually the media and bloggers talk about what FISMA measures and um, well, it doesn’t measure anything, it just requires that agencies have security programs based on a short list of criteria such as security planning, contingency planning, and security testing.  It just goes back to the adage that nobody really knows what FISMA is.
2. FISMA needs to be changed:  As a law, FISMA is exactly where it needs to be.  Yes, Congress does have talks about modifying FISMA, but not much has come of it because what they eventually discover after much debate and sword-waving is that FISMA is the way to write the law about security, the problem is with the execution at all levels–OMB, GAO, and the agencies–and typically across organizational boundaries and competing master agendas.
3. There is a viable alternative framework:  Dancho points out this framework in his post which is really an auditors’ plugin to the existing NIST Framework for FISMA.  Thing is, nobody has a viable alternative framework because it’s still going to be the same people with the same training executing in the same environment.

Urban Cell-Phone Fire Myth photo by richardmasoner.  This myth is dispelled at snopes.com.

Way back last year I wrote a blog post about indicator species and how we’re expecting the metrics to go up based on our continual measuring of them.  Every couple of months I go back and review it to see if it’s still relevant.  And the answer this week is “yes”.

Now I’ve been thinking and talking probably too much about FISMA and the grades over the past couple of years, so occassionally I come to conclusions .  According to Mr Vlad the Impaler, the report card is a bad idea, but I’m slowly beginning to see the wisdom of it:  it’s an opportunity to have a debate and to raise some awareness of Government security outside of those of us who do it.  The only other time that we have a public debate about security is after a serious data breach, and that’s not a happy time.

I just wish the media would stop with the story line that FISMA is failing because the grades provide recursive evidence of it.

Bookmark to:

I remember it like it was March:  Georgia voluntarily adopted FISMA-esque metrics.  I just found the policy statement for what they’re collecting in 2008.  On a side note, all of Georgia’s security policies feature concepts borrowed from NIST, something I like.

Let’s talk about the scope creep of Government security, shall we?  Fact of the matter is, it’s going to happen, and you’ll get eventually get caught up in FISMA if you’re one of the following:

• State and local government
• Government contractor
• Telco
• Government service provider
• COTS software vendor
• Utilities who own “Critical Infrastructure”

Why do I say this?  Mainly because just like how the DoD is discovering that it can’t do its InfoSec job without bringing the civilian agencies along due to connectivity and data-sharing issues, the Federal Government is coming to the point where it can’t secure its data without involving these outside entities.  Some are providers, but the interesting ones are “business partners”–the people that share data with the Government.

State and local government are the ones to watch for this pending scope creep.  The Federal Government works on the premise that the responsibility to protect data follows wherever the data goes–not a bad idea, IMO.  If they transfer data to the states, the states need to inherit the security responsibility and appropriate security controls along with it.

Now if I’m a contractor and exchange data with the Government, this is an easy fix:  they don’t pay me if I don’t play along with their security requirements.  When a new requirement comes along, usually we can haggle over it and both sides will absorb a portion of the cost.  While this might be true for some state programs, it becomes a problem when there is no money changing hands and the Federal Government wants to levy its security policies, standards, etc on the states.  Then it becomes a revolt against an unfunded mandate like RealID.

There are some indicators of Federal Government scope creep in the Georgia policy.  This one’s my favorite:

The performance metrics will also enhance the ability of agencies to respond to a variety of federal government mandates and initiatives, including the Federal Information Security Management Act (FISMA).

Georgia on my Mind by SewPixie.

Bookmark to: