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!

A couple of months before I was activated and went to Afghanistan, I got a briefing from a Special Forces NCO who had done multiple tours in the desert.  One thing he said still sticks in my mind (obviously paraphrased):

“The Afghanis, they live in mud huts, they don’t have electricity, they are stick-people weighing 85 lbs, and to say that we could bomb them into the stone age would be an advancement in their technology level.  But never underestimate these people, they’re survivors.  They’ve survived 35 years of warfare, starting with the Soviets, then they fought a civil war before we arrived on the scene.  Never underestimate their ability to survive, and have respect for them because of who they are.”

Today, I feel the same way about government employees, even more so because it’s an election year:  they’re survivors.

Now time for what I see is the “real” reason why the government is doing badly (if that’s what you believe–opinions differ) at security: it’s all an issue of culture. I have a friend who converted a year ago to a GS-scale employee and took a class on what motivates government employees. Some of these are obvious:

• Pride at making a difference
• Helping people
• Supporting a cause
• Gaining unique experience on a global-class scope
• Job stability
• Retirement benefits

And one thing is noticeably absent: better pay and personal recognition.  Hey, sounds like me in the army.

The Companion Family Plan for Survival at Home photo by Uh … Bob.

Now I’m not trying to stereotype, but you need to know the organizational behavior pieces to understand how government security works. And in this case, the typical government employee is about as survival-aware as their Afghani counterpart.

Best advice I ever heard from a public policy wonk: the key to survival in this town is to influence everything you can get your hands on and never have your name actually written on anything.

In other words, don’t criticize, be nice to everybody even though you think they are a jerk, and avoid saying anything at all because you never know when it will be contrary to the political scene.  The Government culture is a silent culture. That’s why every day amazing things happen to promote security in the Government and you’ll never hear about it on the outside.

One of the reasons that I started blogging was to counter the naysayers who say that FISMA is failing and that the Government would succeed if they would just buy their product for technical policy compliance or end-to-end encryption.  Sadly, the true heroes in Government, the people who just do their job every day and try to survive a hostile political environment, are giving credit to the critics because of their silence.

Which brings me to my point:

Yes, my name is Rybolov and I’m a heretic, but this is the secret to security in the Government:  it’s cultural at all layers of the personnel stack.  Security (and innovation, now that I think about it) needs a culture of openness where it’s allowable to make mistakes and/or criticize.  Doesn’t sound like any government–local, state, or federal–that I’ve ever seen.  However, if you fix the culture, you fix the security.

Bookmark to:

It’s out.  Check it out in the OMB Memo.  I’ll most likely have something pithy to say when I look at it a little bit more, but it looks like it’s mostly the same as last year.

Anyway, you can get it here, it’s OMB Memo 08-21.

Bookmark to:

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:

I’ve touched on this about a bazillion times, let me start today with a very simple statement:  due to the scale of the US Government, we cannot find enough skilled security people.

Part of the problem is that good security people need to know the following skills:

• IT technology: since the data more often than not is in a computer, you need to understand them
• People technology: policies and procedures for managing people
• Business sense:  understanding that you’re supporting business goals
• And for Government:  politics

Back when I was PFC Rybolov, my battalion commander told me something along the lines of “The intelligence world is a hard job, you have to be able to out-infantry the infantry, out-mechanic the mechanics, out-radio the radio guys, and you need to know a language.”  Security is pretty much the same thing–you have to out-techie the techies, out-business the MBAs, and out-jerkify the auditors.  =)

Sound complicated?  Yes, it is, and it’s hard to find people who can do all this.  IT is an employment niche, IT security is a niche to a niche.  And there isn’t enough people who have the experience to do it.

So how do we mitigate the staffing shortage?  Here is what we are doing today in the Government:

• CyberCorps scholarship program for undergrads and graduate students with a minimum government service obligation.
• Using other career fields in “crossover roles”–yes, accountants can be used for some light security tasks.  Some things that we think of as security are really Quality Assurance and Change Control jobs that we have a vested interest in making work.
• Using contractors in some roles such as ISSO, ISSM, etc.
• Automation as much as possible.  Technical is easier, the policy and procedures side takes longer.  What you’ll find out eventually is that good IT management is good security management.
• Hanging on methodologies to “automate” the process side of security.

Now this is cool and all, but it’s hard to sustain and really hard to justify as a long-term solution.  In order to support the Government, we need to create more people.  Cybercorps is a start, but the need is so much larger than the supply that we have to consider better ways to create Government security dweebs.

Do we need Security Awareness and Training?  Yes we do, but much more than what is being provided (think system administrator training and procurement specialist training, not end-user training), and as an internal recruiting pipeline.  Still, I don’t think that we can recruit enough people to “the dark side” and that we need to look outside the Beltway for people.  Problem is that DC is such an insular community and we don’t speak the same language as the rest of the world.

Bookmark to:

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”.

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: