Two months ago, OMB released Memorandum 07-11 which established the authority for government-wide hardening standards for Windows products. It’s a very good thing in my opinion.

However, I’m beginning to see the start of the side effects. I have vendors already that are beating down my door trying to sell me compliance solutions that will help me meet this “oh-so-very-important standard”. I think they missed the other things I’ve had to say about compliance. The one worry that I have is that people will hit their systems with whatever technical policy compliance tool and think that they don’t have to do anything else. I think really that’s the one big problem I have with this entire class of products–they present themselves as the cure-all for all the security problems that an organization could have.

Knowing the people from NIST, it’s the classic problem that they have: They issue guidance and people blindly follow it even though it’s contradictory and not smart security. The best part is when people offer “NIST-Compliant” solutions (I take that out of our marketing material whenever I find it and then take the time to educate people on why it’s wrong) which are at best, “Our interpretation of the guidelines with numerous assumptions” and think that this is all that an organization should do security-wise. Well, the catch is that NIST, compliance frameworks, and vendors can’t anticipate every situation, so at the most what they’re offering is a 75% solution. If you go back to both NIST and OMB, they will tell you to make a decision based on a cost-benefit-risk comparison.

My friend Art Chantker from The Potomac Forum has an executive breakfast on the 24th with a good host of speakers–OMB, NIST, MicroSoft, and US Air Force. I’ll be there, just for the simple fact that I can refute claims later when somebody offers me yet another compliance solution. =)

This whole unified standard business was started by the US Air Force who very simply decreed that you wouldn’t connect a windows system to the network until it met the technical standards. Hmmm, wonder where they got the idea for a technical standard? This isn’t new, DoD has been doing it for years. I guess finally the clueful people got together and decided to make the migration to Vista a chance to get STIGs implemented in the civilian agencies.

• Some Comments on SP 800-39
• Speaking in July/August
• Core Belief #4 — Compliance is a Dead-End
• Special Publication 800-53 Revision 3 Workshop
• Opportunity Costs and the 20 Critical Security Controls

I have one project that I’m looking to staff out in the East side of the beltway. It’s my secret little project that I have to turn loose into the world because I’ve done all I can do for it. It’s now time to turn it over to a decent information security manager and influence the outcome indirectly. Before you ask, no, this isn’t working directly for me, but it’s somebody inside my circle of customers.

Also my long-term goal (over the next year) is to hire somebody to work in Salt Lake City as a generalist security manager and responsible on-site adult. I figure I should start looking now because it’s going to be a long time to find somebody who lives in or wants to live in Utah and who knows how the US Government does security.

• Been Off Teaching
• Some Thoughts on POA&M Abuse
• Sprinkling on the Magic FISMA Fairy Dust
• The MSSP Blues
• OMB Wants a Direct Report

I ran into an interesting scenario yesterday concerning Lines of Business and security.

In case you’ve never heard about LoB, the short story is that each government agency becomes an expert in one area and then sells their services to other agencies. This is good, it gives the executive branch as a whole some economy of scale and significant cost savings. Over the next year and beyond, the Office of Management and Budget (OMB) will be pushing agencies towards LoB offerings from other agencies.

LoB information from the Office of Management and Budget

The problem is, when it comes to the security side of LoB, I don’t think we’ve figured it out yet, and our current security governance model doesn’t work.

Here’s the typical scenario, and it will get more common: If I am an agency who is getting pushed towards using one of the other agencies as a LoB provider, then effectively I’m outsourcing. The problem comes when the provider does not have any security program at all or they do not value the service at the level that I value it at.

No big surprise, security inside the government varies widely. Love it or hate it, that’s what FISMA (the law itself) is aimed to fix, and the highly-scorned FISMA scorecards provide us with a very, very, very high-level metric on an agency-wide basis.

So how do I help/force/coerce my LoB provider to increase their security? This is where the current IT security governance model fails. There are many reasons, here is a short list:

• Current model is focused around one agency owning a system
• Current model does not consider jointly-owned IT systems
• Government does not fully understand a shared service provider model

Inside the Department of Defense, they have a great way to deal with this. They have a system register and everybody puts their system and its vulnerabilities into it. Then if I want to connect or share data with somebody, I can see what all their warts are. However, the civilian agencies are not at this level of maturity.

In order to make LoB work, what needs to happen is for the agencies to learn how to become contractors. This means that if I am offering up a service under LoB and a client agency wants a higher level of security than the system currently provides, then we need to talk about how the funding works out. It doesn’t make sense for the service provider to absorb the cost of the improvements because they don’t have a need for those improvements, but on the other hand it doesn’t make sense for the client agency to pay for 100% of the improvements when the provider agency can now turn around and sell their services to other agencies at a higher rate. Probably the outcome of this discussion is a Memorandum of Agreement with the client agency funding 50% of the improvements.

Short end of this debate is that we need to start having these conversations now.

• Ack! With the Mandates!
• Feds to Embrace SaaS, End is Nigh for Security!
• Compensating Controls
• Clearances and Economy of Scale
• You Didn’t Outsource Your Responsibilities

Nice.  I don’t think they really have a rating for the VA.

http://www.matasano.com/log/798/fisma-using-homeland-security-advisory-system/

• Looking for the Charbo Testimony
• An Informal Study on the Literacy Level of Security Blogs–We All Get Pwned by Amrit
• Upgrading
• Splunk Goes After the FISMA Lucre, They’re not Alone
• My Analysis of the DHS Congressional Testimony

Compliance is a Dead-End

Compliance is aimed at one thing: limiting risks to the organization that writes or enforces the standard.  How’s that for “Bottom Line up Front” writing?

I’ve been a critic of approaching FISMA with an eye toward compliance, and I just recently started to look at PCI.  I’ve started to come around to a different way of thinking.  It all makes perfect sense for the people who write or enforce the standard–they’re cutting their losses and making the non-compliant organization take the blame.  It’s risk management done in a very effective Macchiavellian style.

For an organization looking to improve their security posture, taking a compliance-based approach will eventually implode on itself.  Why?  Because compliance is binary–you are or you’re not.  Risk management is not binary, it’s OK to say “well, we don’t meet the standard here, but we don’t really need to.”

If you base your security on compliance, you are spending too much of your time, people, and money on places where you shouldn’t be, and not enough on where you should be.  In engineering words, you have had your solution dictated to you by a compliance framework.

The endgame of all compliance is either CYA, finger-pointing, or both.  Look at how data breaches with both PCI and the government get spun in the press: “$Foo organization was not compliant with $Bar standard.”  As Adam Shostack says, “Data Breaches are Good for You”, the one caveat being “except when you are caught out of compliance and smeared by the enforcers of the compliance framework”.

I remember a post to the Policy, Standards, Regulations, and Compliance list from Mark Curphey back in the neolithic age of last year about “Do organizations care about compliance or do they care about being caught out of compliance?”  It makes more sense now that I look at it.

On the other side of the coin, what I believe in is risk management.  Risk management realizes that we cannot be compliant with any framework because frameworks are made for a “one size fits all” world.  Sometimes you have to break the rules to follow the rules, and there isn’t room for that in a compliance world.

• When Acceptable Risk is Not Acceptable
• Core Belief #2 — Risk Management Uber Alles
• My 2 Obsessions this Week
• Dictating Common Sense
• An Open Letter to NIST About SP 800-30

I was downtown teaching at the City Club of Washington.  It was my favorite day of the series: Security Test and Evaluation and Risk Management (SPs 800-42, 800-53A, and 800-30).

Earl Crane of ISM-Community fame came jumped in at the last minute (I called him the day before) and gave a good hour worth of presentation on Google hacking and the government.

One thing about the Potomac Forum FISMA Fellows program that is very important to understand:  It’s only for government employees.  The only contractors present are the instructors.  That means two things:

1. We can teach at a very surprising level of depth because we’re not training our competitors.  It leaves the instructors with a bit of a bad aftertaste when you’ve trained somebody to “eat your lunch”.  By restricting the participants to government only, I can teach people exactly how I do things and give them examples to take home in a binder.
2. Students can talk about particular scenarios in their agency without worrying that the information will go anywhere that it’s not supposed to.  There isn’t any press allowed, and no contractors trying to profit from your misfortune (I’m the world’s worst salesman).

Notice the need in there?  Each government agency is siloed into their own little information security management world and there isn’t really a community of peers among the practitioners.  That’s the niche that the FISMA Fellows program is addressing.

Secretly (Maybe not so secretly because it’s now public knowledge), I love it when people come to my classes and then go back to their agency where they become the “this is how you do it right” gadfly.  From time to time I wonder how many people hate me, even though they haven’t met me, simply because I taught their employees how to be a royal PITA.  The smart ones don’t hate me–they keep sending more people to be trained.

• Speaking Again
• FISMA Fellows Spring Cohort
• NIST Framework for FISMA Dates Announced
• C&A Seminar in August, Instructor-to-Coolness Ratio Goes Up!
• C&A Seminar, October 15th and 16th