Post summary: We’re not ready yet culturally.

What spurred this blog post into being is this announcement from ServerVault and Apptis about a Federal Computing Cloud.  I think it’s a pretty ballsy move, and I’ll be watching to see if it works out.

Disclaimer being that at one time I managed security for something similar in a managed services world, only it was built by account with everything being a one-off.  And yeah, we didn’t start our organization the right way, so we had a ton of legacy concepts that we could never shake off, more than anything else about our commercial background and ways of doing things.

Current Theory on Cloud Computing photo by cote.

The way you make money in the managed services world is on standardization and economy-of-scale.  To us mere mortals, it means the following:

• Standardized OS builds
• Shared services where it makes sense
• Shared services as the option of choice
• Split your people’s time between clients
• Up-charge for non-standard configurations
• Refuse one-off configurations on a case-by-case basis

The last 2 were our downfall.  Always eager to please our clients, our senior leadership would agree to whatever one-offs that they felt were necessary for client relationship purposes but without regard to the increased costs and inefficiency when it came time to implement.

Now for those of you out in the non-Government world, let me bring you to the conundrum of the managed services world:  shared services only works in limited amounts.  Yes, you can manage your infrastructure better than the Government does, but they’ll still not like most of it because culturally, they expect a custom-built solution that they own.  Yes, it’s as simple as managing the client’s expectations of ownership v/s their cost savings, and I don’t think we’re over that hurdle yet.

And this is the reason: when it comes to security and cloud computing, the problem is that you’re only as technically literate as your auditors are.  If they don’t understand what the solution is and what the controls are around it, you do not have a viable solution for the public sector.

A “long time ago” (9000 years at least), I created the 2 golden rules for shared infrastructure:

• One customer cannot see another customer.
• One customer cannot affect another customer’s level of service.

And the side-rules for shared infrastructure in the public sector:

• We have a huge set of common controls that you get the documentation to.  It will have my name on it, but you don’t have to spend the money to get it done.
• It’s to my benefit to provide you with transparency in how my cloud operates because otherwise, my solution is invalidated by the auditors.
• Come to us to design a solution, it’s cheaper for you that way.  I know how to do it effectively and more cheaply because it’s my business to know the economics of my cloud.
• You have to give up control in some ways in order to get cost savings.
• There is a line beyond which you cannot change or view because of the 2 golden rules.  The only exception is that I tell you how it’s made, but you can’t see any of the data that goes into my infrastructure.
• If I let you audit my infrastructure, you’ll want to make changes, which can’t happen because of the 2 golden rules.
• I’ll be very careful where I put your data because if your mission data spills into my infrastructure, I put myself at extreme risk.

So, are ServerVault and Apptis able to win in their cloud computing venture?  Honestly, I don’t know.  I do think that when somebody finally figures out how to do cloud computing with the Federal Government, it will pay off nicely.

I think Apptis might be spreading themselves fairly thin at this point, rumor has it they were having some problems last year.  I think ServerVault is in their comfort space and didn’t have to do too much for this service offering.

I can’t help but think that there’s something missing in all of this, and that something is a partnering with the a sponsoring agency on a Line of Business.  FEA comes to mind.

• NIST Cloud Conference Recap
• Reinventing FedRAMP
• Categories of Security Controls in Outsourcing
• Database Activity Monitoring for the Government
• Security Assessments as Fraud, Waste, and Abuse

Go check it out (caveat: .pdf file) and send your comments to sec-cert@nist.gov

I’ve just given it a glance and here are some things that I’ve noticed:

• Section on security in SDLC
• Incorporates some of the concepts in SP 800-39 about enterprise-wide risk
• Section on common controls
• The process has remained pretty much the same but now references all the other core documents

Where I see this revision’s weaknesses:

• Still possible to view the C&A process as happening at the end of the SDLC as a gateway activity.  This is the path to failure–you have to start at the initiation of a project.  In other words, I don’t think the SDLC thing is obvious enough for the constituency.  C&A should be all about security in the SDLC, and I  think we’ve done ourselves a disservice by trying to separate the two.
• Unity:  Yes, we have all the pieces there, but the document doesn’t flow as a whole yet.  BFD, I’ll get over it soon enough.
• It all goes back to metrics:  If completed C&A is going to be one of the core metrics that you use (or OMB uses), then it should be THE core document with everything else being a stub of of it.  We have a start, but I don’t think it’s as fleshed-out as it needs to be.

Side-note for NIST:  C&A is the implementation of the System Security Engineering Process, some of that SSE has a place in 800-37.

The origingal announcement from NIST is this:

NIST, in cooperation with the Office of the Director of National Intelligence (ODNI), the Department of Defense (DOD), and the Committee on National Security Systems (CNSS), announces the completion of an interagency project to develop a common process to authorize federal information systems for operation. The initial public draft of NIST Special Publication 800-37, Revision 1, Guide for Security Authorization of Federal Information Systems: A Security Lifecycle Approach, is now available for a six-week public comment period. The publication contains the proposed new security authorization process for the federal government (currently commonly referred to as certification and accreditation, or C&A). The new process is consistent with the requirements of the Federal Information Security Management Act (FISMA) and the Office of Management and Budget (OMB) Circular A-130, Appendix III, promotes the concept of near real-time risk management based on continuous monitoring of federal information systems, and more closely couples information security requirements to the Federal Enterprise Architecture (FEA) and System Development Life Cycle (SDLC). The historic nature of the partnership among the Civil, Defense, and Intelligence Communities and the rapid convergence of information security standards and guidelines for the federal government will have a significant impact on the federal government’s ability to protect its information systems and networks. The convergence of security standards and guidelines is forging ahead with the development of a series of new CNSS policies and instructions that closely parallel the NIST security standards and guidelines developed in response to FISMA. The CNSS policies and instructions which address the specific areas of security categorization, security control specification, security control assessment, risk management, and security authorization, coupled with the current NIST publications will provide a more unified information security framework for the federal government and its contracting base. The unified approach to information security is brought together in part by the update to NIST Special Publication 800-37, Revision 1, which provides a common security authorization process and references the NIST and CNSS publications for the national security and non national security communities, respectively. The convergence activities mentioned above along with tighter integration of security requirements into the FEA and SDLC processes will promote more consistent and cost-effective information security and trusted information sharing across the federal government. Comments on the IPD of SP 800-37, Revision 1 should be provided by September 30, 2008 and forwarded to the Computer Security Division, Information Technology Laboratory at NIST or submitted via email to: sec-cert@nist.gov .
 

• A New Take on Continuous Controls Monitoring
• CISOin’ Ain’t Easy, But It’s a Living
• Metricon is Next Week
• Oh Lookie, Somebody’s Doing What I Said To Do….
• Federal Computer Week and S.773

While I was slaving away last week, our friends over at NIST published a new version of SP 800-60.  Go check it out at the NIST Pubs Page.

Now for those of you who don’t know what 800-60 is, go check out my 3-part special on the Business Reference Model (BRM), a primer on how SP 800-60 aligning FIPS-199 with the BRM, and a post on putting it all together with a catalog of controls.

And oh yeah, the obligatory press reference: Government Computer News.

Data Release Show photo by Discos Konfort.

So deep down inside, you have to be asking one question by now:  “Why do we need SP 800-60?”  Well, 800-60 does the following:

• Level-sets data criticality across the Government:  Provides a frame of reference for determining criticality–ie, if my data is more important than this but less than this, then it’s a moderate for criticality.
• Counters the tendency to rate system criticality higher than it should be:  Everybody wants to rate their system as high criticality because it’s the safe choice for their career.
• Protection prioritization:  Helps us point out at a national level the systems that need more protection.
• Is regulations-based:  The criticality ratings reflect laws and standards.  For example, Privacy Act Data is rated higher for confidentiality.

All things considered, it’s a pretty decent systemfor Government use.

Now this is where I have a bit of heartburn with GRC tools and data classification in general in the private sector–they classify the wrong things.  How the vendors (not all of them, there is a ton of variation in implementation) want you to categorize your data:

• HIPAA-regulated
• PCI-DSS-regulated
• SOX-regulated
• All other data types

How your CISO needs to categorize data to keep the business afloat:

• Data that gets you paid:  If you’re a business, your #1 priority is getting money.  This is your billing/AR/POS data that needs to keep going.
• Data that keeps you with a product to sale over the next week:  usually ERP data, stuff that slows down the production line.
• Data that people want to rip off your customers:  hey, almost all the regulated data (PCI-DSS, HIPAA, etc) fits in here.
• Data where people will rip you off:  ie, your internal financial systems.  Typically this is SOX country.

I guess really it comes down to the differences between compliance and risk, but in this case, one version will keep you from getting fined, the other will keep your business running.

• An Open Letter to NIST About SP 800-30
• And in This Corner, Special Publication 800-60
• When the Feds Come Calling
• SP 800-53A Now Finally Final
• On the Dangers of SP 800-26

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

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.

• Some Thoughts on Comments to My Blog…
• Learning GovieSpeak: The Plum Book
• Cloud Computing and the Government
• In Which Our Protagonist Discovers We Need More Good Public Policy People Who Understand Security
• Auditors, Frameworks, and Philosophy

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